This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH,RFC] Do not assign stack slots to ssa names
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 12 Jun 2009 17:27:55 +0200
- Subject: Re: [PATCH,RFC] Do not assign stack slots to ssa names
- References: <4A300B3C.4010006@ispras.ru> <4A31D4DD.80007@redhat.com>
On Fri, Jun 12, 2009 at 6:09 AM, Richard Henderson<rth@redhat.com> wrote:
> Andrey Belevantsev wrote:
>>
>> Hi,
>>
>> When processing stack vars partitions for alias export patch, I have
>> noticed that sometimes we get SSA_NAMEs being allocated on stack, e.g.
>> V2SF vectors. ?Richard suggested the attached patch to fix it. ?The
>> patch is bootstrapped and tested (Ada enabled) on x86-64. ?The only
>> failing test is stack protector test ssp-2.c, in which an array and a
>> loop counter get allocated on stack in a different order and thus
>> instead of overflowing the array the test overflows the loop counter and
>> hangs. ?So I've also fixed the test.
>>
>> Michael, what do you think of the patch?
>> Andrey
>>
>>
>> 2009-06-10 ?Richard Guenther ?<rguenther@suse.de>
>> ? ? ? ? ? ?Andrey Belevantsev ?<abel@ispras.ru>
>>
>> ? ? ? ?* cfgexpand.c (expand_one_var): Do not call add_stack_var when
>> original
>> variable is an SSA name.
>
> This doesn't make any sense. ?AFAICT, you're still allocating stack
> space for the variable, just at a different place.
It does make sense in that we currently put SSA names into the stack
coalescing machinery (which this patch avoids to). Doing stack slot
coalescing for SSA name variables causes us to generate aliases
for them - which we do not expect and I believe cannot reasonably
handle (at least definitely not with the alias machinery we currently
have). Micha told me that we will actually never do any coalescing
here anyway, so simply bypassing the machinery should not hurt.
Another approach would be to re-write variables that we cannot put
in registers out-of-SSA again.
Richard.
>