[llvm-commits] [llvm] r45022 - in /llvm/trunk: include/llvm/Target/TargetInstrInfo.h lib/Target/Target.td utils/TableGen/CodeGenInstruction.h utils/TableGen/CodeGenTarget.cpp utils/TableGen/InstrInfoEmitter.cpp

[Bill Wendling]

On Dec 15, 2007, at 1:23 AM, Christopher Lamb wrote:
> On Dec 14, 2007, at 10:40 AM, Bill Wendling wrote:
>> My understanding of a side effect is when an instruction has
>> un-modeled effects. For instance, "emms" on X86 has side effects that
>> aren't modeled in the instruction pattern  -- it resets the FP
>> registers after MMX use. Other instructions have no un-modeled side
>> effects -- e.g., "xor" on X86 or "li" on PPC. Others may have
>> un-modeled side effects in some situations, but not in others --  
>> e.g.,
>> loads, in general, have side effects (accessing memory), but loads
>> from a constant pool don't.
>>
>> This is the working definition, anyway. In the beginning, it'll be
>> closely tied to what the "isRematerializable" flag means. I don't  
>> know
>> what GCC considers side effects. Could you give a summary? It  
>> would be
>> good to contrast/compare with it.
>
>
> In processor design discussions all load instructions were termed  
> "side affecting", as they could cause a page fault. Perhaps the key  
> here is whether the un-modeled effects of the instruction affect  
> correct program behavior?
>
That is the key, yes. :-) We'll leave it up to the individual back  
ends to tell us if moving instructions marked as "may having side  
effects" affects correct program behavior.

-bw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20071216/bb2187ab/attachment.html>