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

Eli Friedman eli.friedman at gmail.com
Mon Jun 14 00:11:09 PDT 2010


On Sun, Jun 13, 2010 at 10:54 PM, Chris Lattner <clattner at apple.com> wrote:
>
> 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".

Added some va_arg optimization stuff in r105934; I don't think the old
entry was very clear, so I rewrote it from scratch.

>>>> -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!

Hmm, all I can find is http://llvm.org/bugs/show_bug.cgi?id=6194 and a
README entry; are there code-quality issues for anything other than
structs with floats in XMM registers?

-Eli




More information about the llvm-commits mailing list