Regression with r200947: [CodeGenPrepare] Move away sign extensions that get in the way of addressing mode.

[Quentin Colombet]

Hi Tom,

I think you find a bug in TargetLoweringBase::isLegalAddressingMode.

Indeed, TargetLoweringBase::isLegalAddressingMode (which is what it is called in your case), says that 3*r + r is a valid addressing mode.
Basically, this returns true for every scale that is not 0, 1, and 2. I believe it misses a default case in the switch statement that return false.

Alternatively, you could have overloaded this function for your target, to be sure it accepts only what it should.

Assuming you fixes this problem, the promotion would still be performed because in that case the transformation is neutral (i.e., we do not create new instructions).
The difference is: instead of selecting:
%in + %sext
we would select:
%in + %promoted_mul

That said, the mul 64bit is not a legal operation on your platform (nor is mul i32), thus, I could drop the change if we did not fold the instruction into the addressing mode when the operation is not legal.

What do you think?

Thanks for the test case.
-Quentin

On Feb 12, 2014, at 12:58 PM, Quentin Colombet <qcolombet at apple.com> wrote:

> Sure, I’m looking into it.
> 
> -Quentin
> 
> On Feb 12, 2014, at 12:03 PM, Tom Stellard <tom at stellard.net> wrote:
> 
>> Hi Quentin,
>> 
>> I've discovered a regression with this commit, please see the attached test case.
>> In this case, CodeGenPrepare is promoting the mul in a sext + mul pattern even
>> though the addressing mode it is creating isn't legal.
>> 
>> One interesting thing about this test case is that if you remove the
>> nsw from the mul instruction, then the incorrect transform does not
>> take place.  I'm not sure why this matters.  Would you mind taking a look?
>> 
>> Thanks,
>> Tom
>> <codegen-prepare-addrmode-sext.ll>
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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