From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30769 invoked by alias); 24 Oct 2014 09:01:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 30687 invoked by uid 89); 24 Oct 2014 09:01:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail.emea.novell.com Received: from mail.emea.novell.com (HELO mail.emea.novell.com) (130.57.118.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 09:01:38 +0000 Received: from EMEA1-MTA by mail.emea.novell.com with Novell_GroupWise; Fri, 24 Oct 2014 10:01:34 +0100 Message-Id: <544A31900200007800041C83@mail.emea.novell.com> Date: Fri, 24 Oct 2014 09:11:00 -0000 From: "Jan Beulich" To: "Jakub Jelinek" ,"Jeff Law" Cc: , Subject: Re: avoid alignment of static variables affecting stack's References: <5448BCA30200007800041508@mail.emea.novell.com> <20141023065015.GX10376@tucnak.redhat.com> <5448C5CB0200007800041532@mail.emea.novell.com> <5449454A.9050502@redhat.com> In-Reply-To: <5449454A.9050502@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2014-10/txt/msg02495.txt.bz2 >>> On 23.10.14 at 20:13, wrote: > On 10/23/14 01:09, Jan Beulich wrote: >>>>> On 23.10.14 at 08:50, wrote: >>> On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote: >>>> Function (or more narrow) scope static variables (as well as others not >>>> placed on the stack) should also not have any effect on the stack >>>> alignment. I noticed the issue first with Linux'es dynamic_pr_debug() >>>> construct using an 8-byte aligned sub-file-scope local variable. >>>> >>>> According to my checking bad behavior started with 4.6.x (4.5.3 was >>>> still okay), but generated code got quite a bit worse as of 4.9.0. >>> >>> If the static/external var has BLKmode, then perhaps it is safe, but I >>> wonder about other vars, say vectors etc. Such vars are most likely >>> loaded from their memory location, and if for some reason that needs to= be >>> spilled again, stack realignment would not be able to do that. >>> Or do we inspect the IL and for any pseudos with modes needing larger >>> alignment we adjust the dynamic stack realignment fields? >> >> I don't know, but it would seem to me that this ought to happen >> anyway: If the pseudo holds the result of some computation >> other than a simple load from memory and needs spilling, the same >> would apply afaict. >=20 > For something in static storage, this seems OK. However, I think a hard= =20 > register variable ought to be left alone -- even if we can't spill it to= =20 > a stack slot today, there's a reasonable chance we might add that=20 > capability in the future. Hmm, but then wouldn't it need to be the code generating the spill that's responsible for enforcing suitable alignment? I can certainly re-submit without the hard register special cased (as it would still fix the original issue I'm seeing), but it feels wrong to do so. Jan