[llvm-commits] [llvm] r45620 - /llvm/trunk/lib/Target/X86/X86InstrInfo.cpp

[Bill Wendling]

On Jan 5, 2008, at 12:53 AM, Evan Cheng wrote:
> Right. If it's a load from GV and GVRequiresExtraLoad() returns true
> then it's a load from a stub.
>
Okay. Once I did the check, it now seems to treat the example program:

volatile char G[100];
int B(char *F, int N) {
   for (; N > 0; --N)
     F[N] = G[N];
}

correctly for static compilation. Thanks Evan & Chris. :-)

> Here is something to consider for further enhancement. There are
> potentially other GV loads which can be side effect free though. As
> 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.
>


> 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?
>
-bw