[LLVMdev] Shouldn't DAGCombine insert legal nodes?

[Scott Michel]

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