[llvm-commits] [llvm] r55292 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/fold-call-2.ll

[Dan Gohman]

Not offhand. Is callseq_start a no-op on all targets, when
there's no alloca?

BTW, this there's an X86/README.txt entry on this that
you can remove, the one beginning
"Another instruction selector deficiency".

Dan

On Aug 25, 2008, at 2:57 PM, Evan Cheng wrote:

> callseq_start is completely eliminated unless there is an alloca, but
> in that case FP is used to do reload. I think we are safe. Can you
> think of an unsafe situation?
>
> Evan
>
> On Aug 25, 2008, at 12:51 PM, Dan Gohman wrote:
>
>>
>> On Aug 24, 2008, at 12:19 PM, Evan Cheng wrote:
>>
>>> Author: evancheng
>>> Date: Sun Aug 24 14:19:55 2008
>>> New Revision: 55292
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=55292&view=rev
>>> Log:
>>> Move callseq_start above the call address load to allow load to be
>>> folded into the call node.
>>
>> What happens if the callseq_start involves a non-trivial stack
>> pointer adjustment and the load's address is spilled and needs
>> to be reloaded? Could this change cause the reload to happen
>> from the wrong stack location?
>>
>> Dan
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits