This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Darwin, ppc] constrain processor usage for m32.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]