I just ran across something interesting: DAGCombine inserts a 64-bit constant as the result of converting a (bitconvert (fabs val)) to a (and (bitconvert val), i64const). The problem: i64 constants have to be legalized for the CellSPU platform. DAGCombine is doing the right thing but it's not doing the right thing for CellSPU and it's damed difficult to work around this "feature". Moreover, the way all of SelectionDAGLegalize and DAGCombne's code is written, it's particularly difficult to "re- legalize" nodes unless one more legalization pass is invoked after DAGCombine. It's not like it's actually easy to load an i64 constant while maintaining the vector register uniformity that CellSPU expects. In fact, there're a lot of different ways to load a 64-bit constant depending on the constant's value. At worse case, it's a constant pool load on a memory-constrained machine (256K). But it can be a lot better than paying the 6-cycle penalty for memory loads. OTOH, that's why I created all of that legalization code in the first place so the backend could get it right. Suggestions apart from doing custom fabs legalization in CellSPU (sorta defeats the purpose of DAGCombine, no)? -scooter
Before anyone asks: yes using i64 on the Cell's SPUs is a really bad and stupid idea. But, I have to support the data type to make gcc happy. Nonetheless, i64 constants have to be legalized. -scooter On Jan 19, 2009, at 6:36 PM, Scott Michel wrote:> I just ran across something interesting: DAGCombine inserts a 64-bit > constant as the result of converting a (bitconvert (fabs val)) to a > (and (bitconvert val), i64const). > > The problem: i64 constants have to be legalized for the CellSPU > platform. DAGCombine is doing the right thing but it's not doing the > right thing for CellSPU and it's damed difficult to work around this > "feature". Moreover, the way all of SelectionDAGLegalize and > DAGCombne's code is written, it's particularly difficult to "re- > legalize" nodes unless one more legalization pass is invoked after > DAGCombine. > > It's not like it's actually easy to load an i64 constant while > maintaining the vector register uniformity that CellSPU expects. In > fact, there're a lot of different ways to load a 64-bit constant > depending on the constant's value. At worse case, it's a constant > pool load on a memory-constrained machine (256K). But it can be a lot > better than paying the 6-cycle penalty for memory loads. > > OTOH, that's why I created all of that legalization code in the first > place so the backend could get it right. > > Suggestions apart from doing custom fabs legalization in CellSPU > (sorta defeats the purpose of DAGCombine, no)? > > > -scooter > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> wrote:> I just ran across something interesting: DAGCombine inserts a 64-bit > constant as the result of converting a (bitconvert (fabs val)) to a > (and (bitconvert val), i64const). > > The problem: i64 constants have to be legalized for the CellSPU > platform. DAGCombine is doing the right thing but it's not doing the > right thing for CellSPU and it's damed difficult to work around this > "feature". Moreover, the way all of SelectionDAGLegalize and > DAGCombne's code is written, it's particularly difficult to "re- > legalize" nodes unless one more legalization pass is invoked after > DAGCombine.I don't think DAGCombine should be doing a transform like that post-legalize; if it is, it's probably a bug. -Eli
Right. DAGCombine will insert *illegal* nodes before legalize. Evan On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote:> On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> wrote: >> I just ran across something interesting: DAGCombine inserts a 64-bit >> constant as the result of converting a (bitconvert (fabs val)) to a >> (and (bitconvert val), i64const). >> >> The problem: i64 constants have to be legalized for the CellSPU >> platform. DAGCombine is doing the right thing but it's not doing the >> right thing for CellSPU and it's damed difficult to work around this >> "feature". Moreover, the way all of SelectionDAGLegalize and >> DAGCombne's code is written, it's particularly difficult to "re- >> legalize" nodes unless one more legalization pass is invoked after >> DAGCombine. > > I don't think DAGCombine should be doing a transform like that > post-legalize; if it is, it's probably a bug. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev