<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 16, 2008, at 11:12 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="blue" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="Section1"><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" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "> </span></font></p><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="3" color="navy" face="Times New Roman"><span style="font-size: 12pt; color: navy; ">Chris,</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="3" color="navy" face="Times New Roman"><span style="font-size: 12pt; color: navy; ">I did not quite understand the “The bad thing about …” part of your argument. I’m not sure which of the two scenarios are you comparing (promoting in FrontEnd vs BackEnd) or (promotion to int vs i32)</span></font></div></div></div></div></span></blockquote><div><br class="webkit-block-placeholder"></div><div>Assume we make the change I suggested. This means that this C function (on x86-32):</div><div><br class="webkit-block-placeholder"></div><div>char foo() { </div><div> char c = ...</div><div> return c;</div><div>}</div><div><br class="webkit-block-placeholder"></div><div>would compile to something like:</div><div><br class="webkit-block-placeholder"></div><div>define i32 @foo() {</div><div> ...</div><div> %tmp = sext i8 ... to i32</div><div> ret i32 %tmp</div><div>} </div><div><br class="webkit-block-placeholder"></div><div>Since "char" is sign extend to 32 bits on this target, there would be an explicit sign extension. This is goodness. The problem is that now you have a caller:</div><div><br class="webkit-block-placeholder"></div><div> ...</div><div>char bar() {</div><div> char x = foo()</div><div> return char;</div><div>}</div><div><br class="webkit-block-placeholder"></div><div>This would get compiled (by the front-end to something like this:</div><div><br class="webkit-block-placeholder"></div><div>define i32 @bar() {</div><div> ; call</div><div> %tmp = call i32 @foo()</div><div> %x = trunc i32 %tmp to i8</div><div><br class="webkit-block-placeholder"></div><div> ; return</div><div> %tmp2 = sext i8 to i32</div><div> ret i32 %tmp2</div><div>}</div><div><br class="webkit-block-placeholder"></div><div>The problem with this is that we now have a trunc+sext instruction that cannot be eliminated. The loss here is that while foo returns an i32 value, we lost the fact that the top 25 bits all have the same value (i.e. that it is a sign extended 8-bit value). Because of this, we can't eliminate the trunc+sext pair in bar, pessimizing code (and in a very common case!). I am just saying that we should have some attribute (or something) on foo that indicates its result is actually sign extended, allowing the optimizer to zap the trunc+sext in bar.</div><div><br class="webkit-block-placeholder"></div><br><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="blue" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="Section1"><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'; "><span class="Apple-style-span" style="color: rgb(20, 79, 174); font-size: 12px; -webkit-text-stroke-width: -1; ">The standard allows calling a function without prototype and assumes “int” return value; and I realize that this is the primary reason why the return value is being promoted. This ties this promotion to int type and not the size of any register in target, which in turn makes it a language issue rather than code generation issue; hence FrontEnd must take care of it.</span></p></div></div></div></span></blockquote><div><br class="webkit-block-placeholder"></div><div>Right, I agree this should be fixed.</div><br><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="blue" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="Section1"><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="3" color="navy" face="Times New Roman"><span style="font-size: 12pt; color: navy; "> </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="3" color="navy" face="Times New Roman"><span style="font-size: 12pt; color: navy; ">Now for our port, things are different. In most (sane) ports, the target provides an integer class for int… however, things are different in our (insane) port. We only have an 8-bit data bus but we also want 16-bit int type. So this promotion will make char return values (which are used heavily in many application in 8-bit environment) quite inefficient. So we need a way to turn off this promotion all together and deal with default function prototype in a different way (perhaps issue a diagnostic …)</span></font></div></div></div></div></span></blockquote><div><br class="webkit-block-placeholder"></div><div>Sure. The other good thing about exposing this extensions in the IR is that interprocedural optimizations can eliminate them. This gives the optimizer the ability to actually eliminate the extensions and truncations completely.</div></div><br><div>-Chris</div></body></html>