llvm dev - Apr 2015 - [LLVMdev] Does LLVM optimize rudimentary i16 -> i32 conversions

In my language there are a lot of i16 definitions, but almost all of the
time they are upgraded to i32 because my add operations only happen on i32.

So to be representative to my language definition, I have a lots of
Sext/Zext and Truncs pretty much every time I add or subtract.

As soon as I pass through InstCombine things look much nicer, all the
upcasts and downcasts go away, but my test cases are simple.

Is InstCombine pretty good about finding most/all such cases?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150417/04cee200/attachment.html>

In general, yes.  Other passes may catch cases InstCombine doesn't. You 
may find some corner cases here and there.  Bug reports or patches are 
very welcome.  The largest area of potential concern is likely to be 
widdening/narrowing for induction variables in loops. I know we've hit 
one such issue recently.

I'm assuming you're compiling for a 32 bit or 64 bit architecture. If 
not, the answer might be extremely different.

Philip

On 04/17/2015 09:00 PM, Dave Pitsbawn wrote:
> In my language there are a lot of i16 definitions, but almost all of 
> the time they are upgraded to i32 because my add operations only 
> happen on i32.
>
> So to be representative to my language definition, I have a lots of 
> Sext/Zext and Truncs pretty much every time I add or subtract.
>
> As soon as I pass through InstCombine things look much nicer, all the 
> upcasts and downcasts go away, but my test cases are simple.
>
> Is InstCombine pretty good about finding most/all such cases?
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150420/beb493b9/attachment.html>

An important data point is if your uses are i16 also.  trunc(sext(a) +
sext(b)) == a + b == trunc(zext(a) + zext(b)) always, so instcombine
should always be able to remove the truncs, sexts and zexts in these
cases.

However, if your uses are i32 uses (i.e. you compute sext(a) + sext(b)
and use that i32 value) then getting rid one of the sexts and
optimizing sext(a)+sext(b) to sext(a + b) cannot be done unless LLVM
has some extra information about the relative ranges of a and b (via
the nsw flag, via control flow etc.).  Similar arguments apply for
zexts.

-- Sanjoy

On Mon, Apr 20, 2015 at 3:57 PM, Philip Reames
<listmail at philipreames.com> wrote:
> In general, yes.  Other passes may catch cases InstCombine doesn't. 
You may
> find some corner cases here and there.  Bug reports or patches are very
> welcome.  The largest area of potential concern is likely to be
> widdening/narrowing for induction variables in loops.  I know we've hit
one
> such issue recently.
>
> I'm assuming you're compiling for a 32 bit or 64 bit architecture. 
If not,
> the answer might be extremely different.
>
> Philip
>
>
> On 04/17/2015 09:00 PM, Dave Pitsbawn wrote:
>
> In my language there are a lot of i16 definitions, but almost all of the
> time they are upgraded to i32 because my add operations only happen on i32.
>
> So to be representative to my language definition, I have a lots of
> Sext/Zext and Truncs pretty much every time I add or subtract.
>
> As soon as I pass through InstCombine things look much nicer, all the
> upcasts and downcasts go away, but my test cases are simple.
>
> Is InstCombine pretty good about finding most/all such cases?
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>