llvm dev - Feb 2009 - [LLVMdev] Adding legal integer sizes to TargetData

On Feb 2, 2009, at 1:26 PM, Dale Johannesen wrote:
>
> On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote:
>
>> 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.
>
> I basically agree with Scott on this:  we shouldn't reintroduce  
> types that
> are illegal for the target after Legalize.
I'm sorry, to be clear, this is mostly talking about an instcombine  
change.  Obviously anything in codegen should respect current  
restrictions.  The question is whether the mid-level optimizer should  
try to avoid introducing illegal types.

-Chris

On Feb 2, 2009, at 1:29 PMPST, Chris Lattner wrote:
>
> On Feb 2, 2009, at 1:26 PM, Dale Johannesen wrote:
>
>>
>> On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote:
>>
>>> 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.
>>
>> I basically agree with Scott on this:  we shouldn't reintroduce
>> types that
>> are illegal for the target after Legalize.
>
> I'm sorry, to be clear, this is mostly talking about an instcombine
> change.  Obviously anything in codegen should respect current
> restrictions.  The question is whether the mid-level optimizer should
> try to avoid introducing illegal types.
I understand; I was stating a general principle, which I believe to be  
a good one.

I have always found this issue a little thorny on compilers. On one  
hand, we want to remove unnecessary IR instructions in general as that  
would reduce IR instruction count that could speed up compilation and  
and it can also simplify target independent optimization passes  
because it can assume certain code patterns will not occur after  
running some cleanup phase.  On the other hand,  I agree with Dale  
that it's generally not a good idea for a transformation to introduce  
an illegal type that would need to be undone in the code generation  
phase.

For this particular case, it sounds like undoing this transformation  
in CodeGen is not easy given our current framework and doing the  
optimization doesn't help making other transformation simpler (e.g.,  
loop bound calculations).  If that is the case, the fix that you are  
suggesting seems to be the right approach.

-- Mon Ping



On Feb 2, 2009, at 1:33 PM, Dale Johannesen wrote:
>
> On Feb 2, 2009, at 1:29 PMPST, Chris Lattner wrote:
>
>>
>> On Feb 2, 2009, at 1:26 PM, Dale Johannesen wrote:
>>
>>>
>>> On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote:
>>>
>>>> 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.
>>>
>>> I basically agree with Scott on this:  we shouldn't reintroduce
>>> types that
>>> are illegal for the target after Legalize.
>>
>> I'm sorry, to be clear, this is mostly talking about an instcombine
>> change.  Obviously anything in codegen should respect current
>> restrictions.  The question is whether the mid-level optimizer should
>> try to avoid introducing illegal types.
>
> I understand; I was stating a general principle, which I believe to be
> a good one.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev