<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Tom,<div><br></div><div>I think you find a bug in TargetLoweringBase::isLegalAddressingMode.</div><div><br></div><div>Indeed, TargetLoweringBase::isLegalAddressingMode (which is what it is called in your case), says that 3*r + r is a valid addressing mode.</div><div>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.</div><div><br></div><div>Alternatively, you could have overloaded this function for your target, to be sure it accepts only what it should.</div><div><br></div><div>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).</div><div>The difference is: instead of selecting:</div><div>%in + %sext</div><div>we would select:</div><div><div>%in + %promoted_mul</div></div><div><br></div><div>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.</div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks for the test case.</div><div><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">-Quentin</div>
</div>
<br><div><div>On Feb 12, 2014, at 12:58 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Sure, I’m looking into it.<div><br><div apple-content-edited="true">
<div style="font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">-Quentin</div>
</div>
<br><div style=""><div>On Feb 12, 2014, at 12:03 PM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Quentin,<br><br>I've discovered a regression with this commit, please see the attached test case.<br>In this case, CodeGenPrepare is promoting the mul in a sext + mul pattern even<br>though the addressing mode it is creating isn't legal.<br><br>One interesting thing about this test case is that if you remove the<br>nsw from the mul instruction, then the incorrect transform does not<br>take place. I'm not sure why this matters. Would you mind taking a look?<br><br>Thanks,<br>Tom<br><span><codegen-prepare-addrmode-sext.ll></span></blockquote></div><br></div></div>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br></blockquote></div><br></div></body></html>