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: PR target/40838: gcc shouldn't assume that the stack is aligned


On Sun, Oct 18, 2009 at 9:19 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Sat, 17 Oct 2009, Richard Guenther wrote:
>
>> > I can't rely on automatic variables for vectorizer when I need
>> > the information before RTL expansion.
>>
>> I don't see how this is too late (I also don't see where expand creates
>> automatic variables,
>
> assign_temp/assign_stack_temp, all over.
>
>> but well ... I can imagine reload creating spill slots). ?If non-aligned
>> automatic variables are generated you simply use unaligned moves -
>> what's the problem?
>
> It's obvious: we don't want to generate unaligned moves. ?That's the whole
> point of H.J. patches. ?He has a phase ordering problem:
> (a) alignment of generated temporaries depends on known stack alignment
> (b) known stack alignment depends on what is put on stack (including late
> ? ?generated temporaries)
>
> He tries to solve this by pessimistically assuming that potentially
> everything imaginable could go on stack. ?What I don't understand is why
> we don't instead track hard_stack_alignment in assign_*_temp (where we
> then assume that the stack will be aligned perfectly), and expand stack
> realignment code _after_ having expanded everything else (plus examined
> local variables for the possibility of generating spill slots).

I also don't understand how this problem can be solved in the vectorizer
and how this problem cannot occur the same way when using
intrinsics.

Richard.


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