[LLVMdev] Adding legal integer sizes to TargetData
clattner at apple.com
Mon Feb 2 01:06:03 CST 2009
Now that 2.5 is about to branch, I'd like to bring up one of Scott's
favorite topics: certain optimizers widen or narrow arithmetic,
without regard for whether the type is legal for the target. In his
specific case, instcombine is turning an i32 multiply into an i64
multiply in order to eliminate a cast. This does simplify/reduce the
number of IR operations, but an i64 multiply is dramatically more
expensive than an i32 multiply on CellSPU.
There are a couple of different ways to look at this. On the one
hand, I still strongly believe that codegen should be able to re-
narrow operations (and it does on his testcase on i386). However,
codegen is currently doing these optimizations on a per-basic block
basis, and we're not likely to have whole-function dags in the near
future, so there is an inherent limit to its power.
An earlier place to handle this is in codegen prepare, which is
global. However, the bad thing about this is that it would
effectively require duplicating all the type legalization code in CGP,
which is a pass we want to shrink, not grow. OTOH, the whole CGP pass
is really a hack around selection dags not being whole-function.
A third way to handle this is to add to target data a notion of
"native types". Instcombine could then be constrained to not do the
widening/narrowing transformations when the original type (i32 in this
case) was native but the destination type (i64) is non-native.
On the one hand, adding this to targetdata is simple and straight-
forward with well-defined semantics. OTOH, it is somewhat ugly that
IR canonicalization gets a bit more target-specific. On the third
hand, instcombine already promotes indices of GEPs to match the
pointer size etc, so it wouldn't be too crazy for it to do this.
What do others think about this?
More information about the LLVMdev