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: Improve stack layout heuristic.


On Sun, Apr 17, 2011 at 11:27 PM, Easwaran Raman <eraman@google.com> wrote:
> On Sun, Apr 17, 2011 at 1:39 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> On Sun, Apr 17, 2011 at 9:39 PM, Easwaran Raman <eraman@google.com> wrote:
>>> @@ -372,8 +366,9 @@
>>> ? ? ? ? ? ? ? ? to elements will conflict. ?In case of unions we have
>>> ? ? ? ? ? ? ? ? to be careful as type based aliasing rules may say
>>> ? ? ? ? ? ? ? ? access to the same memory does not conflict. ?So play
>>> - ? ? ? ? ? ? ? ?safe and add a conflict in this case. ?*/
>>> - ? ? ? ? ? ? || contains_union)
>>> + ? ? ? ? ? ? ? ?safe and add a conflict in this case when -fstrict-aliasing
>>> + ? ? ? ? ? ? ? ? is used. ?*/
>>> + ? ? ? ? ? ? || (contains_union && flag_strict_aliasing))
>>> ? ? ? ? ? ?add_stack_var_conflict (i, j);
>>> ? ? ? ?}
>>> ? ? }
>>
>> Are you sure this change is safe? See http://gcc.gnu.org/PR25654
>>
>> Ciao!
>> Steven
>>
>
> I tried the test case in PR25654 and with my patch and on -O2
> -fno-strict-aliasing ?it puts the two variables in the same partition
> and the test passes. My understanding of that issue is that with
> -fstrict-aliasing, the short * and int * are assumed to point to
> different locations and hence they can't share stack slots, but with
> -fno-strict-aliasing that assumption is not valid.

That's correct.  With -fno-strict-aliasing all accesses conflict.

If you'd have split up the patch I'd have approved the change above already.
I'm just not familiar with the other parts of the coalescing code.

So feel free to install the above change separately (after testing it
separately).

Thanks,
Richard.

> Thanks,
> Easwaran
>


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