From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-289756-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22317 invoked by alias); 18 Apr 2011 09:23:16 -0000
Received: (qmail 22308 invoked by uid 22791); 18 Apr 2011 09:23:15 -0000
X-SWARE-Spam-Status: No, hits=-2.3 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST
X-Spam-Check-By: sourceware.org
Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Apr 2011 09:22:41 +0000
Received: by wye20 with SMTP id 20so4514090wye.20        for <gcc-patches@gcc.gnu.org>; Mon, 18 Apr 2011 02:22:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.172.7 with SMTP id j7mr35352wbz.60.1303118560256; Mon, 18 Apr 2011 02:22:40 -0700 (PDT)
Received: by 10.227.0.140 with HTTP; Mon, 18 Apr 2011 02:22:39 -0700 (PDT)
In-Reply-To: <BANLkTikEGSs7-fcKGnxi0YSwqKBfzQ3R-Q@mail.gmail.com>
References: <BANLkTi=eOcYh1av=mW==s5ZL4oviR7994w@mail.gmail.com>	<BANLkTikMOhbUtknHAPkHbT_w-h9TR5Bk-g@mail.gmail.com>	<BANLkTikEGSs7-fcKGnxi0YSwqKBfzQ3R-Q@mail.gmail.com>
Date: Mon, 18 Apr 2011 09:29:00 -0000
Message-ID: <BANLkTinwPSW2Uj_wj-meKERyYwM0J6zN1Q@mail.gmail.com>
Subject: Re: Improve stack layout heuristic.
From: Richard Guenther <richard.guenther@gmail.com>
To: Easwaran Raman <eraman@google.com>
Cc: Steven Bosscher <stevenb.gcc@gmail.com>, gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-04/txt/msg01360.txt.bz2

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> wrot=
e:
>>> @@ -372,8 +366,9 @@
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to elements will conflict. =A0In case o=
f unions we have
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to be careful as type based aliasing ru=
les may say
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 access to the same memory does not conf=
lict. =A0So play
>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0safe and add a conflict in this case. =
=A0*/
>>> - =A0 =A0 =A0 =A0 =A0 =A0 || contains_union)
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0safe and add a conflict in this case w=
hen -fstrict-aliasing
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is used. =A0*/
>>> + =A0 =A0 =A0 =A0 =A0 =A0 || (contains_union && flag_strict_aliasing))
>>> =A0 =A0 =A0 =A0 =A0 =A0add_stack_var_conflict (i, j);
>>> =A0 =A0 =A0 =A0}
>>> =A0 =A0 }
>>
>> 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 =A0it 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
>