Re: [rfc] stack alignment macro cleanup

2010-10-05 Thread Richard Henderson
On 10/04/2010 04:24 PM, H.J. Lu wrote: As I remembered, -mforce-drap exposed issues with register allocator. ix86_force_drap is only referenced in one place in i386.c. I'd like to keep it. I don't see why it can't be moved to generic. It may expose problems for other targets. I doubt very

Re: [rfc] stack alignment macro cleanup

2010-10-05 Thread H.J. Lu
On Tue, Oct 5, 2010 at 8:57 AM, Richard Henderson r...@redhat.com wrote: On 10/04/2010 04:24 PM, H.J. Lu wrote: As I remembered, -mforce-drap exposed issues with register allocator. ix86_force_drap is only referenced in one place in i386.c. I'd like to keep it.  I don't see why it can't be

Re: [rfc] stack alignment macro cleanup

2010-10-05 Thread H.J. Lu
On Tue, Oct 5, 2010 at 8:57 AM, Richard Henderson r...@redhat.com wrote: On 10/04/2010 04:24 PM, H.J. Lu wrote: As I remembered, -mforce-drap exposed issues with register allocator. ix86_force_drap is only referenced in one place in i386.c. I'd like to keep it.  I don't see why it can't be

Re: [rfc] stack alignment macro cleanup

2010-10-04 Thread Paul Brook
I would like to reduce this to STACK_BOUNDARY -- minimum alignment enforced by hardware. ... -- unchanged This may be determined by factors other than hardware. For example the ARM EABI requires that the stack be 8-byte aligned at public entry points. However within a function the

Re: [rfc] stack alignment macro cleanup

2010-10-04 Thread Richard Henderson
On 10/04/2010 11:00 AM, Paul Brook wrote: Your proposal doesn't make this problem any worse, if anything it's better because we don't have to device between S_B and PREFERRED_STACK_BOUNDARY. I'm just noting that documenting this as a hardware property is at best misleading. Well, I'm

Re: [rfc] stack alignment macro cleanup

2010-10-04 Thread Richard Henderson
On 10/02/2010 04:03 PM, H.J. Lu wrote: MIN_STACK_BOUNDARY (undocumented; local to i386 atm) -- appears to be the ABI specified stack boundary, i.e. the minimum that must be in place at a call site. This somehow differs from I_S_B due to proliferation of command-line options. It is

Re: [rfc] stack alignment macro cleanup

2010-10-04 Thread Paul Brook
Your proposal doesn't make this problem any worse, if anything it's better because we don't have to device between S_B and PREFERRED_STACK_BOUNDARY. I'm just noting that documenting this as a hardware property is at best misleading. Well, I'm hoping to document that it *is* a hardware

Re: [rfc] stack alignment macro cleanup

2010-10-04 Thread H.J. Lu
On Mon, Oct 4, 2010 at 11:27 AM, Richard Henderson r...@redhat.com wrote: On 10/02/2010 04:03 PM, H.J. Lu wrote: MIN_STACK_BOUNDARY  (undocumented; local to i386 atm)  -- appears to be the ABI specified stack boundary, i.e.  the minimum that must be in place at a call site.  This  somehow

[rfc] stack alignment macro cleanup

2010-10-02 Thread Richard Henderson
Currently we have STACK_BOUNDARY -- minimum alignment enforced by hardware. PREFERRED_STACK_BOUNDARY -- a preserved alignment greater than what the hw enforces (defaults to STACK_BOUNDARY) INCOMING_STACK_BOUNDARY -- an alignment provided by callers on function entry. (defaults to

Re: [rfc] stack alignment macro cleanup

2010-10-02 Thread H.J. Lu
On Sat, Oct 2, 2010 at 1:01 PM, Richard Henderson r...@redhat.com wrote: Currently we have STACK_BOUNDARY  -- minimum alignment enforced by hardware. PREFERRED_STACK_BOUNDARY  -- a preserved alignment greater than what the hw enforces  (defaults to STACK_BOUNDARY) INCOMING_STACK_BOUNDARY