[llvm-commits] CVS: llvm/lib/Target/X86/X86InstrFPStack.td X86InstrInfo.cpp X86InstrInfo.h X86InstrInfo.td X86InstrMMX.td X86InstrSSE.td

Evan Cheng evan.cheng at apple.com
Tue Jun 19 11:09:45 PDT 2007


On Jun 19, 2007, at 10:54 AM, Chris Lattner wrote:

>>>> I don't see a better way so I guess this will be a targetinstrinfo
>>>> bit (true for those with side-effects).
>>>
>>> Okay, the tricky thing here is instructions that have "conditional
>>> side effects".  For example, all instructions marked isload/isstore/
>>> iscall etc should be considered to have side effects (as would
>>> anything with implicit definitions), but loads from constant pools
>>> and other special cases should not be considered to have side
>>> effects.
>>
>> Calls should definitely be marked to have side-effects. To me the
>> tricky cases are loads / stores. But can't we determine these from
>> the operands? So, add one more condition:
>> 3. if memory operation, no external symbol or global address inputs.
>>
>> Then we don't need to mark loads / stores as having side effects.
>
> Ah right, even better.  So you're saying we don't need a new flag at
> all?

We do need a "hasSideEffect" flag. There are some non-branch, non- 
load/store instructions that have side effects, no?

>
> I guess this won't work right now though, because we don't model
> things that clobber the condcodes.  Wouldn't it be nice if we did? :)

Yeah, I hear you. It's coming. Those flag clobbering instructions  
just have to be marked "hasSideEffect" for now.

Evan

>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list