[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 10:22:28 PDT 2007

On Jun 19, 2007, at 9:40 AM, Chris Lattner wrote:

> On Jun 19, 2007, at 9:38 AM, Evan Cheng wrote:
>>>> If we are really concerned about the speed, then I agree the hybrid
>>>> approach is the best. Sorry about the confusion.
>>> Speed is something to consider, but I don't think it should override
>>> maintainability.
>>>> Not to mention I had already considered the "trivial
>>>> rematerialization"
>>>> scheme to be temporary.
>>> Okay, how do you think this should work going forward?
>> Trivial remat will go away when proper remat is implemented. All
>> instructions without side-effect will be rematerializable if their
>> operands are available so all these will go away. Not that proper
>> remat is coming anytime soon though.
> Ok.  How do you intend to capture the "without side-effects" part?
> It seems that simple remat works for things that:
> 1. have no side effects
> 2. have no register inputs
> Is there another condition?

Can't think of any.

> If so, simple remat can check #2 today, just by itself looking at the
> machineinstr.  Given that, it comes down to how we want to  
> represent #1.

I don't see a better way so I guess this will be a targetinstrinfo  
bit (true for those with side-effects).


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