[llvm-commits] [llvm] r105303 - /llvm/trunk/lib/Target/X86/README-X86-64.txt

[Chris Lattner]

On Jun 12, 2010, at 6:46 PM, Eli Friedman wrote:

>>> -It jumps over the movaps that do not need to be stored. Hard to see this being
>>> -significant as it added 5 instruciton (including a indirect branch) to avoid
>>> -executing 0 to 8 stores in the function prologue.
>>> -
>>> -Perhaps we can optimize for the common case where no XMM registers are used for
>>> -parameter passing. i.e. is %al == 0 jump over all stores. Or in the case of a
>>> -leaf function where we can determine that no XMM input parameter is need, avoid
>>> -emitting the stores at all.
> 
> We have a jump over the stores if %al == 0.  I guess we don't try to
> detect the case where no floats are passed to va_arg, but that's
> practically impossible without large changes to the way we lower
> va_arg to IR.

GCC does an indirect jump to get exactly the number of restores needed, llvm always does 0 or all of them.  I don't know of this is really important or not.

Incidentally, GCC does a very nice optimization when it can tell that all the va_args calls are of non-vector/fp types and when the a va_list doesn't escape from a function: it doesn't save the fp/vector registers.

It seems that the llvm optimizer could determine this and capture the classes of va_arg'd stuff in an extra argument to llvm.vastart or something.  This is a pretty big win in stuff like this:

void test(int x, ...) {
}

GCC compiles this to an empty function, we... don't.  IIRC, the original justification for this was in functions like libc's "open".

>>> -For problem 4, the parameter 'd' would be moved to the front of the parameter
>>> -list so it will be passed in register:
>>> -    void %test(int %d,
>>> -               long %undef1, long %undef2, long %undef3, long %undef4,
>>> -               long %undef5, long %undef6,
>>> -               long %s.i, byte %s.j, long %s.d);
>>> -
> 
> I'm pretty sure argument passing on x86-64 works. :)  And we have a
> bug on adding an ABI-lowering library to LLVM.

Ah ok.  We still do many things that are terrible for code quality, but if this was about correctness, I'm all for removing it.  Thanks Eli!

-Chris