<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 12, 2014, at 2:07 PM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Feb 12, 2014 at 01:43:25PM -0800, Quentin Colombet wrote:<br><blockquote type="cite">Hi Tom,<br><br>I think you find a bug in TargetLoweringBase::isLegalAddressingMode.<br><br>Indeed, TargetLoweringBase::isLegalAddressingMode (which is what it is called in your case), says that 3*r + r is a valid addressing mode.<br>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.<br><br>Alternatively, you could have overloaded this function for your target, to be sure it accepts only what it should.<br><br>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).<br>The difference is: instead of selecting:<br>%in + %sext<br>we would select:<br>%in + %promoted_mul<br><br>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.<br><br></blockquote></div></blockquote><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>I think it makes sense to avoid the promotion if the result can't be<br>folded into the addressing mode.</div></blockquote><div>Well, that is a bit more complex than this.</div><div>When it is neutral, it may still be a good idea to perform the transformation because it may expose more simplifications (like sext + load).</div><div>However, I would prefer the promotion not to be smart about that, at least for now.</div><div><br></div><div>Therefore, I still think that checking for an operation to be legal or not may still be a viable approach.</div><div><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> How will you determine whether or not an<br>operation is legal?<br></div></blockquote>TLI.isOperationLegalOrCustom?</div><div><br></div><div>See the attached patch for an example of implementation.</div><div><br></div><div>If this serves your purposes, let me know when you fixed the isLegalAddressingMode and I will commit this patch with your test case.</div><div><br></div><div>As it is the matched thinks the mul is folded anyway, making the proposed tuning useless.</div><div><br></div><div>Thanks,</div><div>-Quentin</div><div></div></body></html>