[llvm-commits] [llvm] r55292 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/fold-call-2.ll
gohman at apple.com
Mon Aug 25 17:36:19 PDT 2008
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".
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?
> 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
>>> 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?
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits