525412 - lirasm: need to fix ABI problems with user-defined functions

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

lirasm has an odd problem.

The problem is this:  for call sites we just name the ABI (e.g. "icall foo 
fastcall a b c") and the argument marshalling is done within the assembler.
But for callee blocks the argument marshalling is explicit in the LIR asm.
This is bad because the meaning of "cdecl", for example, is different across
different platforms, which makes it impossible to write platform-independent
lirasm tests.

So I think we'll need to add some syntax to say "this block implements a
function using ABI xyz", and then the argument marshalling on the callee
side would also be generated within the assembler.  Eg. consider this from 
multfrag3.in:

  .begin avg
  p1 = param 0 0
  p2 = param 1 0
  sum = add p1 p2
  two = int 2
  avg = div sum two
  ret avg
  .end

(It implements the calling convention that is called "fastcall" on i386
but "cdecl" on X64.)  This would become something like this:

  .begin_func avg fastcall p1 p2
  sum = add p1 p2
  two = int 2
  avg = div sum two
  ret avg
  .end

lirasm would generate the appropriate LIR at the start of the block.  (This
is a little different to how calls are handled;  for them the marshalling
code is generated directly by the code generator as native code rather than
as LIR.  I guess this difference is because up until now calls have only ever been made to functions written in C, functions haven't been written in LIR.)

----

Also, not all platforms implement "fastcall", but we can't have them falling
over if they encounter it in an asm file.  So for those platforms it
should be a synonym for "cdecl".

Comment 1

[Jacob Bramley [:jbramley]]

Indeed; the last three lirasm tests fails on ARM with "no fastcall support".

Comment 2

[Graydon Hoare :graydon]

Attachment: remove the dead check

Actually "fastcall"-ness and the NO_FASTCALL symbol mostly have to do with whether your compiler understands the "fastcall" attribute. Nothing to do with the ABI support: if the assembler sees ABI_FASTCALL on x64 it treats it like ABI_CDECL, for example. The only platforms that are even aware of ABI_FASTCALL are i386 and ARM, and they both handle the ABI explicitly in their handling of asm_param. So just removing the guard from lirasm gets rid of the problem on x64. 

It also gets rid of the "no fastcall" error on ARM, but doesn't turn ARM green. Why? Because ARM seems to not be able to assemble LIR_div at all! Ha ha ha. Ok, new bug for that one.

Comment 3

[Nicholas Nethercote [inactive]]

What would happen if you had a call that used one of the other ABIs (STDCALL or THISCALL)?  Does asm_param() handle that as well?

Comment 4

[Graydon Hoare :graydon]

(In reply to comment #3)
> What would happen if you had a call that used one of the other ABIs (STDCALL or
> THISCALL)?  Does asm_param() handle that as well?

Yes. "LIR_param n 0" means "nth parameter in the current ABI", whatever that ABI is.

Comment 5

[Graydon Hoare :graydon]

http://hg.mozilla.org/projects/nanojit-central/rev/280b05e48279

Comment 6

[Nicholas Nethercote [inactive]]

(In reply to comment #4)
>
> Yes. "LIR_param n 0" means "nth parameter in the current ABI", whatever that
> ABI is.

Great!  Looks like my diagnosis was wrong.

But what dictates the ABI used by a user-defined block?

Comment 7

[Graydon Hoare :graydon]

It's determined by the callers. The callers mutate the callinfo, before assembly commences and therefore before any interpretation of LIR_param has to be made.

If your callers have disagreements, the last one assembled clobbers. Perhaps not ideal -- I'm not saying the current approach is *good* -- merely that it seems to work.

Comment 8

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/fd7facb8aa24