<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 14, 2008, at 10:43 AM, <<a href="mailto:Alireza.Moshtaghi@microchip.com">Alireza.Moshtaghi@microchip.com</a>> <<a href="mailto:Alireza.Moshtaghi@microchip.com">Alireza.Moshtaghi@microchip.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">In this thread I’m trying to merge two email threads into one, because both discuss the same problem that’s troubling us and I would like to reach a conclusion on what would be the best approach.</span></font></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">To minimize the size of this thread I only mention the subject of the other two threads:</span></font></div><div style="text-indent: -24pt; margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">(1)<font size="1" face="Times New Roman"><span style="font: normal normal normal 7pt/normal 'Times New Roman'; "> <span class="Apple-converted-space"> </span></span></font></span></font><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">[LLVMdev] Integer promotion of return node operand (initiated by Sachin)</span></font></div><div style="text-indent: -24pt; margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">(2)<font size="1" face="Times New Roman"><span style="font: normal normal normal 7pt/normal 'Times New Roman'; "> <span class="Apple-converted-space"> </span></span></font></span></font><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">[LLVMdev] trouble with 32-bit promotion of return value (initiated by myself)</span></font></div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; "> </span></font></p><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">To summarize:</span></font></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">Evan has replied to thread (1) and suggested to add a calling convention and check for it in visitRet</span></font></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">Dan replied to thread (2) and suggested to add a new field to the TargetLowering class, and then let each target specify the minimum integer type to promote return types to</span></font></div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; "> </span></font></p><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font size="2" face="Courier New"><span style="font-size: 10pt; font-family: 'Courier New'; ">Either way, I think we all agree that the root of the problem is the FIXME in SelectionDAGLowering::visitRet()</span></font></div></div></div></span></blockquote><br></div><div>Hi Ali,</div><div><br class="webkit-block-placeholder"></div><div>I think there are two sides to this issue. The ultimate problem is that the code generator has a builtin assumption that sizeof(int) = 32 bits. IIRC, this comes into play in two places:</div><div><br class="webkit-block-placeholder"></div><div>1. Arguments to calls are known to be sign/zero extended to int in certain cases.</div><div>2. The return value of functions is implicitly promoted.</div><div><br class="webkit-block-placeholder"></div><div>Lets talk about #2 first, because it is the simplest case. Here the front-end types the function as (f.e.) returning i8, and then has the code generator insert the extension to (for example) i32. The attribute on the function tells the code generator whether to sign or zero extend it.</div><div><br class="webkit-block-placeholder"></div><div>To me, the solution to this is to have the C front-end insert an explicit extension of the appropriate type to the right size. This would mean that the code generator would now never insert the extension. Since the C front-end knows the size of int, on your target, you could have it extend to 16 or 8 bits, as appropriate. This is also good, because the extension is exposed to the mid-level optimizer, allowing it to be eliminated more aggressively.</div><div><br class="webkit-block-placeholder"></div><div>The bad thing about doing this is that, on the caller side, we lose information. With the current approach, the caller knows that the value is (for example) 8 bits but sign or zero extended as appropriate. This allows the caller side to do optimizations based on this fact. If all return values were i32, we wouldn't know that the top 24 bits were sign/zero extended. I think we can handle this by adding some new attributes, but this is marginally ugly.</div><div><br class="webkit-block-placeholder"></div><div>What do you think?</div><div><br class="webkit-block-placeholder"></div><div>-Chris</div></body></html>