> Did you see this Ali? > http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txtWould you mind adding it to SVN? Would make it easier to comment on. In particular, it would be nice to add examples for X86 (caller extends. High bits undefined in the callee) and PPC (callee extends). And I still don't understand why in short y(); int z() { return ((int)y() << 16) >> 16; } we can remove the sign extension on x86 (I really think we cannot).> -ChrisThanks, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Rafael Espindola wrote:>> Did you see this Ali? >> http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt > > Would you mind adding it to SVN? Would make it easier > to comment on. In particular, it would be nice to add > examples for X86 (caller extends. High bits undefined > in the callee) and PPC (callee extends). > > And I still don't understand why in > > short y(); > int z() { > return ((int)y() << 16) >> 16; > } > > we can remove the sign extension on x86 (I really think we cannot).I still don't think llvm needs to do this. We had the discussion on http://groups.google.com/group/ia32-abi/browse_thread/thread/f47e0106b21d9269 The conclusion: --- I think callers need to assume that return value is in %al and that the upper bits of %eax are undefined. If the caller needs a 32-bit sign- or zero-extended value, it needs to do the extend itself. I believe GCC, ICC, and MSVC all behave this way. Given that, it shouldn't matter how the callee handles the upper bits. It should do whatever is most convenient. --- Andrew.
> I still don't think llvm needs to do this. We had the discussion on > http://groups.google.com/group/ia32-abi/browse_thread/thread/f47e0106b21d9269 > > The conclusion: > > --- > I think callers need to assume that return value is in %al and that > the upper bits of %eax are undefined. If the caller needs a 32-bit > sign- or zero-extended value, it needs to do the extend itself. I > believe GCC, ICC, and MSVC all behave this way. > > Given that, it shouldn't matter how the callee handles the upper > bits. It should do whatever is most convenient.Exactly. Note that y returns a short, and z wants an int. It is z's responsibility to do a sign extension. The example claims that a sign extension is not necessary.> --- > > Andrew. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
On Mar 31, 2009, at 12:04 PM, Rafael Espindola wrote:>> Did you see this Ali? >> http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt > > Would you mind adding it to SVN? Would make it easier > to comment on. In particular, it would be nice to add > examples for X86 (caller extends. High bits undefined > in the callee) and PPC (callee extends).Sure, I checked it in here: llvm/docs/ExtendedIntegerResults.txt It's not a great long term location, but should be fine in the meantime. Ali said: Could you please add that stuff to your proposal as well? Defining the textual syntax of how these attrs would be used will eliminate many ambiguities in the discussion. I think syntax along the lines of signext(13) and zeroext(13) would make sense. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090401/a5bf5961/attachment.html>
> I think syntax along the lines of signext(13) and zeroext(13) would > make sense.Yes, while knowing that something was extended from i13 is not too useful for ABI stuff, the optimizers might want to add such attributes if they work out that the returned value is always extended from the lower 13 bits for example. This is also useful for languages like Ada which may know that several top bits are always zero etc due to their strong type system. Ciao, Duncan.