Changes in directory llvm/lib/Target/X86:
X86InstrFPStack.td updated: 1.10 - 1.11
X86InstrInfo.cpp updated: 1.92 - 1.93
X86InstrInfo.h updated: 1.67 - 1.68
X86InstrInfo.td updated: 1.308 - 1.309
X86InstrMMX.td updated: 1.33 - 1.34
X86InstrSSE.td updated: 1.186 - 1.187
---
Log message:
Revert
How about this proposal (Obviously feel free to pick better names for
these things):
1. Reintroduce the 'isremat-able' flag, set it to true for all the
instructions that are *potentially* rematerializable.
2. Add a virtual target hook that can override the flag:
I'm sorry to be such a pain, but this seems like a step backward.
We've gone from having an explicit flag in the .td files to having
another magic table in the .cpp file (somewhat amusing because
'duplicable' just made the opposite transition).
How about this proposal (Obviously feel
On Jun 18, 2007, at 10:29 PM, Chris Lattner wrote:
Hi Dan,
I'm sorry to be such a pain, but this seems like a step backward.
We've gone from having an explicit flag in the .td files to having
another magic table in the .cpp file (somewhat amusing because
'duplicable' just made the
This achieves two things:
1. Just looking at the .td file, you can tell which instructions are
candidates for remat.
2. The isRematerializable predicate is faster for instructions that
are not remat-able.
3. The isReallyRematerializable only needs to be implemented by
targets with
On Jun 19, 2007, at 8:06 AM, Chris Lattner wrote:
This achieves two things:
1. Just looking at the .td file, you can tell which instructions are
candidates for remat.
2. The isRematerializable predicate is faster for instructions that
are not remat-able.
3. The isReallyRematerializable
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
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
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
On Jun 19, 2007, at 10:31 AM, Chris Lattner wrote:
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
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
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/
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
Changes in directory llvm/lib/Target/X86:
X86InstrFPStack.td updated: 1.9 - 1.10
X86InstrInfo.cpp updated: 1.91 - 1.92
X86InstrInfo.h updated: 1.66 - 1.67
X86InstrInfo.td updated: 1.307 - 1.308
X86InstrMMX.td updated: 1.32 - 1.33
X86InstrSSE.td updated: 1.183 - 1.184
---
Log message:
Replace
14 matches
Mail list logo
