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

[Evan Cheng]

On Aug 25, 2008, at 5:36 PM, Dan Gohman wrote:

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

That's the case on x86 for sure. I need to check other target code to  
know for sure, but I think it's frequently true.

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

Ok! Thanks.

Evan

>
>
> 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
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits