[llvm-commits] [llvm] r155136 - in /llvm/trunk: lib/Transforms/InstCombine/InstCombineShifts.cpp test/Transforms/InstCombine/2010-11-01-lshr-mask.ll test/Transforms/InstCombine/apint-shift.ll test/Transforms/InstCombine/cast.ll test/Transforms/In

[Nick Lewycky]

On 19 April 2012 14:08, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

>
> On Apr 19, 2012, at 11:40 AM, Nick Lewycky <nlewycky at google.com> wrote:
>
> On 19 April 2012 09:46, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>
>>  Author: stoklund
>> Date: Thu Apr 19 11:46:26 2012
>> New Revision: 155136
>>
>> These transformations are deferred:
>>
>>  (X >>? C) << C   --> X & (-1 << C)  (When X >> C has multiple uses)
>>  (X >>? C1) << C2 --> X << (C2-C1) & (-1 << C2)   (When C2 > C1)
>>  (X >>? C1) << C2 --> X >>? (C1-C2) & (-1 << C2)  (When C1 > C2)
>>
>
> If the form on the left is better, please make sure that we turn the code
> on the right into the code on the left.
>
>
> I don't think we should do that.
>
> InstCombine doesn't actually have a way of knowing which expression is
> better, so it will just leave them alone so it at least doesn't break
> anything.
>

The major goal of instcombine is to pick one of two equivalent code
constructs, so that the backend and other IR-level optimizers can detect
one pattern instead of both. Please make sure that we pick one.

SCEV is unusual in that it prefers arithmetic operations to bitwise
operations; usually bitwise operations are easier to reason about because
they don't carry. There is already logic in SCEV to detect an "or" which is
actually an "add", and I think the right fix is to extend that. The premise
is that it's easier to find an "or" which is an "add" than it is to find an
"add" that is an "or". I'd be interested in hearing if you disagree with
that?

DAGCombine is better equipped to decide that.
>

Right, the reality of the situation is that the IR-level optimizers don't
know what's best for the given architecture, etc., and we end up with two
fighting optimizers. Usually I decide which of the two patterns should be
canonical by checking whether the existing X86 backend handles one of them
better. I don't have a good answer overall.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120419/b127f588/attachment.html>