PING: [PATCH 4.5]: Fix PR39146 unneccesary stack realign
H.J. Lu
hjl.tools@gmail.com
Thu Apr 2 17:44:00 GMT 2009
On Fri, Mar 27, 2009 at 4:10 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Mar 3, 2009 at 10:36 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Mar 3, 2009 at 6:55 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> - Show quoted text -
>>> On Mon, Mar 2, 2009 at 10:10 PM, Ye, Joey <joey.ye@intel.com> wrote:
>>>> Update testcase. OK for 4.5?
>>>>
>>>> Please move it to gcc.target/i386/stackalign and remove
>>>
>>> I think this test belongs to gcc.target/i386/stackalign. But
>>> it isn't that important.
>>>
>>>>
>>>> /* { dg-require-effective-target lp64 } */
>>>
>>> You didn't remove this. This test should be run for 32bit.
>>>
>>>> You can use
>>>>
>>>> /* { dg-final { scan-assembler-not "and\[lq\]?\[\\t \]*\\$-32,\[\\t
>>>> \]*%\[re\]?sp" } } */
>>>>
>>>>
>>>
>>> I think
>>>
>>> /* { dg-final { scan-assembler-not "and\[lq\]?\[^\\n\]*-32,\[^\\n\]*sp" } } */
>>>
>>> will work for Windows.
>>
>> Here is the revised patch. We should set max_used_stack_slot_alignmen
>> to actual alignment used. Also there is no need to update for alignment
>> of argument on stack since it will be properly aligned by caller. OK for
>> 4.5 if there are regressions on Linux/ia32, Linux/ia64 and Linux/x86-64?
>>
>> Thanks.
>>
>> --
>> H.J.
>> ---
>> gcc/
>>
>> 2009-03-03 Joey Ye <joey.ye@intel.com>
>>
>> PR middle-end/39146
>> * cfgexpand.c (get_decl_align_unit): Update
>> max_used_stack_slot_alignment with align instead of
>> stack_alignment_needed.
>>
>> * function.c (assign_stack_local_1): Update
>> max_used_stack_slot_alignment with alignment_in_bits instead
>> of stack_alignment_needed.
>> (locate_and_pad_parm): Don't update max_used_stack_slot_alignment
>> here.
>>
>> gcc/testsuite/
>>
>> 2009-03-03 Joey Ye <joey.ye@intel.com>
>> H.J. Lu <hongjiu.lu@intel.com>
>>
>> PR middle-end/39146
>> * gcc.target/i386/stackalign/pr39146.c: New.
>>
>
> PING.
>
Tested on Linux/ia32, Linux/ia64 and Linux/x86-64. OK for trunk?
Thanks.
--
H.J.
More information about the Gcc-patches
mailing list