[llvm-commits] [llvm] r105303 - /llvm/trunk/lib/Target/X86/README-X86-64.txt
Chris Lattner
clattner at apple.com
Sun Jun 13 22:54:09 PDT 2010
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
More information about the llvm-commits
mailing list