[llvm-commits] [llvm] r45620 - /llvm/trunk/lib/Target/X86/X86InstrInfo.cpp
clattner at apple.com
Sat Jan 5 11:21:30 PST 2008
>> I am not 100% sure, but I think that
>> is the place to start looking.
> Right. If it's a load from GV and GVRequiresExtraLoad() returns true
> then it's a load from a stub.
> Here is something to consider for further enhancement. There are
> potentially other GV loads which can be side effect free though. As
LICM at the LLVM level should catch these.
> the comment says, if the value in the GV isn't redefined (in the
> loop), then it can be moved. Should there be some kind of callback
> function provided by caller of isReallySideEffectFree() that checks
> if a register or a GV operand is considered side effect free? In the
> case of LICM, if a register or GV operand is considered a loop
> invariant, then the instruction is really side effect free. In the
> case of remat, if an operand is "available", then it's side effect
> free, etc. etc.
You could theoretically check to see that it is a load from a global
which is marked constant, but...
> BTW, what do we do about volatile loads? I don't think the property
> is transferred to target instructions. Or perhaps volatile property
> should be on the location (GV) instead of the instruction?
Right, this isn't captured. It's safe to do the xform from loads from
stubs because we know they are never volatile. A load from a global
could be volatile.
More information about the llvm-commits