[PATCH] [MIPS] fix extension of integer types (function calls)

Daniel Sanders daniel.sanders at imgtec.com
Tue Apr 28 03:09:25 PDT 2015


In http://reviews.llvm.org/D9198#162375, @petarj wrote:

> In http://reviews.llvm.org/D9198#162163, @dsanders wrote:
>
> > > IIRC from a recent discussion, unsigned 32-bit int are represented in a 64-bit register as sign-extended value of the 32-bit value (i.e. bit 31 is copied through the top half). So, the caller has to make sure the value is correctly represented before making a call, right?
> >
> >
> > That's correct in general, all the 32-bit operations sign-extend their result to 64-bit. The ABI documentation is trying to match this architectural behaviour but that didn't seem to be what was actually implemented in gcc.
>
>
> My understanding is that the called function should assume sign-extended (both signed and unsigned) 32-bit integers as inputs on its entry and compiler can base decisions on that. One [1] of Strahinja's previous patches was led by a bug when floating point value was NOT sign-extended but zero-extended before the call, and that led to an incorrect behaviour in the called function. For that particular case, GCC was sign-extending the value before making a call.
>
> I know this area is not well defined, this is why I brought another example to take into account before any decision is made.
>
> [1] http://reviews.llvm.org/D7791


Unfortunately, it's even less well defined in the documentation for softfloat float's. I believe both compilers treat them as if they were 32-bit integers which seems like the sensible thing to do.


http://reviews.llvm.org/D9198

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the cfe-commits mailing list