llvm dev - Jan 2007 - [LLVMdev] Effective Sign Extension Elimination

Hey all,

Now that we have sign/zero extensions, have people given thought to  
the elimination of these? There's a paper I downloaded a few years  
ago called "Effective Sign Extension Elimination" by M. Kawahito, H.  
Komatsu, and T. Nakatani.

I only have a dead tree copy of it, though. But I can share it as  
much as I can.

-bw

a quick google finds the paper here:

http://www.trl.ibm.com/projects/jit/paper/sxt.pdf

Bill Wendling wrote:
> Hey all,
>
> Now that we have sign/zero extensions, have people given thought to  
> the elimination of these? There's a paper I downloaded a few years  
> ago called "Effective Sign Extension Elimination" by M. Kawahito,
H.
> Komatsu, and T. Nakatani.
>
> I only have a dead tree copy of it, though. But I can share it as  
> much as I can.
>
> -bw
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Thu, 4 Jan 2007, Bill Wendling wrote:
> Now that we have sign/zero extensions, have people given thought to
> the elimination of these? There's a paper I downloaded a few years
> ago called "Effective Sign Extension Elimination" by M. Kawahito,
H.
> Komatsu, and T. Nakatani.
Sign extension elimination is most useful in the backend, when targeting 
processors like PowerPC that have a single register width (e.g. 32-bits). 
We already do quite a bit of sign extension removal in the dag combiner, 
but this is limited to a single basic block at a time.  In the future, I'd 
like to extend the selectiondag to work on entire functions at a time, 
which would increase the scope of this optimization, but this isn't likely 
to happen in the near future.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

C ABI requires function parameters and return value to be promoted to  
32-bit. Perhaps we can eliminate these extensions at IPO time if both  
caller and callee agrees to break the ABI convention? This can have  
minor performance impact on targets with sub-registers (e.g. x86).

Evan

On Jan 4, 2007, at 2:02 PM, Chris Lattner wrote:
> On Thu, 4 Jan 2007, Bill Wendling wrote:
>> Now that we have sign/zero extensions, have people given thought to
>> the elimination of these? There's a paper I downloaded a few years
>> ago called "Effective Sign Extension Elimination" by M.
Kawahito, H.
>> Komatsu, and T. Nakatani.
>
> Sign extension elimination is most useful in the backend, when  
> targeting
> processors like PowerPC that have a single register width (e.g. 32- 
> bits).
> We already do quite a bit of sign extension removal in the dag  
> combiner,
> but this is limited to a single basic block at a time.  In the  
> future, I'd
> like to extend the selectiondag to work on entire functions at a time,
> which would increase the scope of this optimization, but this isn't  
> likely
> to happen in the near future.
>
> -Chris
>
> -- 
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Jan 4, 2007, at 2:02 PM, Chris Lattner wrote:
> On Thu, 4 Jan 2007, Bill Wendling wrote:
>> Now that we have sign/zero extensions, have people given thought to
>> the elimination of these? There's a paper I downloaded a few years
>> ago called "Effective Sign Extension Elimination" by M.
Kawahito, H.
>> Komatsu, and T. Nakatani.
>
> Sign extension elimination is most useful in the backend, when  
> targeting
> processors like PowerPC that have a single register width (e.g. 32- 
> bits).
> We already do quite a bit of sign extension removal in the dag  
> combiner,
> but this is limited to a single basic block at a time.  In the  
> future, I'd
> like to extend the selectiondag to work on entire functions at a time,
> which would increase the scope of this optimization, but this isn't  
> likely
> to happen in the near future.
>
Okay. That sounds like a good idea. Perhaps this paper/idea can be  
revisited when the SelectionDAG works on a function at a time. (From  
a cursory reading of it, and from what I remember, it's a global  
optimization.)

-bw