Displaying 4 results from an estimated 4 matches for "recsed".
Did you mean:
recased
2009 Feb 23
0
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...t (for example) in the node is unnecessary
and a really dangerous thing to do. It is unnecessary because it can
be computed on demand (as we do now) and it is dangerous, because it
means that a) clients have to keep it up to date as they change the
shuffle mask, and b) the nodes need to be reCSEd as the operands are
changed.
> I attempted to be pretty thorough with the change before committing.
> I ran through the tests before committing. The changes were
> primarily method invocations, which admittedly were pretty numerous.
> It wasn't as if I was adding DebugLoc...
2009 Feb 23
2
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...le) in the node is unnecessary and a really
> dangerous thing to do. It is unnecessary because it can be computed on
> demand (as we do now) and it is dangerous, because it means that a) clients
> have to keep it up to date as they change the shuffle mask, and b) the nodes
> need to be reCSEd as the operands are changed.
I can take the result caching out, seemed to be a good idea at the time. The
predicate is only called in a couple of places and I was prematurely
optimizing for the case when it's called repeatedly.
However, (b) is something that is handled elsewhere. BuildVecto...
2009 Feb 23
4
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
Chris:
I did float this by the dev list first a couple of weeks ago, didn't receive
any comments. It's not entirely gratuitous; the rationale for adding a new
node class is threefold:
a) Convenience for the backends. Since it benefits multiple backends (PPC
and CellSPU), it's a logical addition. I reckon the GPU efforts would also
benefit.
b) Where else would one encapsulate a
2009 Feb 23
0
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...he node is unnecessary
> and a really dangerous thing to do. It is unnecessary because it
> can be computed on demand (as we do now) and it is dangerous,
> because it means that a) clients have to keep it up to date as they
> change the shuffle mask, and b) the nodes need to be reCSEd as the
> operands are changed.
>
> I can take the result caching out, seemed to be a good idea at the
> time. The predicate is only called in a couple of places and I was
> prematurely optimizing for the case when it's called repeatedly.
>
> However, (b) is something...