| Message ID | BF346973-7FFC-4809-8F42-3A3BACBCE2E0@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug.
Hum, do you have an example of something that fails? I ask, cause I think the if you say that you have a 64-bit processor, then, generating code for a 64-bit processor isn't necessarily wrong. If you say you have a 64-bit processor, then you likely have an OS that runs on that processor, and that OS I'm thinking will save and restore the full 64-bit registers. If not, do you have a pointer to documentation that says this won't work?
On Sat, Jul 21, 2012 at 10:27 AM, Mike Stump <mikestump@comcast.net> wrote: > On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote: >> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug. > > Hum, do you have an example of something that fails? I ask, cause I think the if you say that you have a 64-bit processor, then, generating code for a 64-bit processor isn't necessarily wrong. If you say you have a 64-bit processor, then you likely have an OS that runs on that processor, and that OS I'm thinking will save and restore the full 64-bit registers. If not, do you have a pointer to documentation that says this won't work? In fact OS_MISSING_POWERPC64 was added because GNU/Linux does not have support but Darwin has the support in the OS. The whole point of -mpu=G5 means generate G5 code which includes generating PowerPC64 code. This was added explicitly to speed up code like crafty in SPEC. Do you have any data that says it should be disabled? If you don't want to generate powerpc64 code then use -mno-powerpc64. Thanks, Andrew Pinski
Hi Mike, On 21 Jul 2012, at 18:27, Mike Stump wrote: > On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote: >> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug. > > Hum, do you have an example of something that fails? I can look for something, if necessary. > I ask, cause I think the if you say that you have a 64-bit processor, then, generating code for a 64-bit processor isn't necessarily wrong. indeed, highly desirable to make use of any improvements available. > If you say you have a 64-bit processor, then you likely have an OS that runs on that processor, and that OS I'm thinking will save and restore the full 64-bit registers. If not, do you have a pointer to documentation that says this won't work? Mac_OS_X_ABI_Function_Calls.pdf pp 19 para 2 (box). This stipulates that even on a 64 bit processor, only the lower 32 bits of nonvolatile registers are saved/restored. All 64 bits are saved across context switches/asynchronous events. That is to quote the doc: one can *only* use the full 64 bits 'between function calls' safely. If there's a different mechanism for enforcing what's implied above, then we could use that. cheers Iain
On Sat, Jul 21, 2012 at 10:56 AM, Iain Sandoe <iain@codesourcery.com> wrote: > Hi Mike, > > On 21 Jul 2012, at 18:27, Mike Stump wrote: > >> On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote: >>> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug. >> >> Hum, do you have an example of something that fails? > > I can look for something, if necessary. > >> I ask, cause I think the if you say that you have a 64-bit processor, then, generating code for a 64-bit processor isn't necessarily wrong. > > indeed, highly desirable to make use of any improvements available. > >> If you say you have a 64-bit processor, then you likely have an OS that runs on that processor, and that OS I'm thinking will save and restore the full 64-bit registers. If not, do you have a pointer to documentation that says this won't work? > > Mac_OS_X_ABI_Function_Calls.pdf pp 19 para 2 (box). This stipulates that even on a 64 bit processor, only the lower 32 bits of nonvolatile registers are saved/restored. All 64 bits are saved across context switches/asynchronous events. > > That is to quote the doc: one can *only* use the full 64 bits 'between function calls' safely. > > If there's a different mechanism for enforcing what's implied above, then we could use Yes HARD_REGNO_CALL_PART_CLOBBERED should work. If that is not working there is a bug somewhere else in the compiler. Thanks, Andrew Pinski
On 21 Jul 2012, at 19:02, Andrew Pinski wrote: >> If there's a different mechanism for enforcing what's implied above, then we could use > > Yes HARD_REGNO_CALL_PART_CLOBBERED should work. If that is not > working there is a bug somewhere else in the compiler. thanks, that looks solid enough, will have to delve a bit deeper, re the original issue. Iain
Index: gcc/config/rs6000/darwin.h =================================================================== --- gcc/config/rs6000/darwin.h (revision 189712) +++ gcc/config/rs6000/darwin.h (working copy) @@ -398,6 +398,9 @@ extern int darwin_emit_branch_islands; default, as kernel code doesn't save/restore those registers. */ #define OS_MISSING_ALTIVEC (flag_mkernel || flag_apple_kext) +/* When building m32 code, we cannot use POWERPC64. */ +#define OS_MISSING_POWERPC64 !TARGET_64BIT + /* Darwin has support for section anchors on powerpc*. It is disabled for any section containing a "zero-sized item" (because these are re-written as size=1 to be compatible with the OSX ld64).