From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7694 invoked by alias); 18 Oct 2009 19:44:22 -0000 Received: (qmail 7685 invoked by uid 22791); 18 Oct 2009 19:44:22 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-vw0-f178.google.com (HELO mail-vw0-f178.google.com) (209.85.212.178) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 18 Oct 2009 19:44:18 +0000 Received: by vws8 with SMTP id 8so2626181vws.0 for ; Sun, 18 Oct 2009 12:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.114.142 with SMTP id e14mr7194702vcq.83.1255895056970; Sun, 18 Oct 2009 12:44:16 -0700 (PDT) In-Reply-To: References: <20090806214216.GA14439@lucon.org> <6dc9ffc80910171114k2ed87800s7a307c671a563a7d@mail.gmail.com> <84fc9c000910171151l22f64266gf95010521ca205a@mail.gmail.com> <6dc9ffc80910171202n34b6403fm9fe90fe1af3480d5@mail.gmail.com> <84fc9c000910171220l1bb7668q7d597061ea9a5eb5@mail.gmail.com> <6dc9ffc80910171229u38ddfbf2m8ce1e2a9faa0745a@mail.gmail.com> <84fc9c000910171235p6f23ba3at22436dad2c4a22ca@mail.gmail.com> <6dc9ffc80910171246v19b116eby6ae6b01803e3affa@mail.gmail.com> <84fc9c000910171301xd87370eyada33fd9ae1bfd75@mail.gmail.com> Date: Sun, 18 Oct 2009 19:45:00 -0000 Message-ID: <84fc9c000910181244i1915b4fdjb188544ece831a45@mail.gmail.com> Subject: Re: PATCH: PR target/40838: gcc shouldn't assume that the stack is aligned From: Richard Guenther To: Michael Matz Cc: "H.J. Lu" , Ian Lance Taylor , Uros Bizjak , gcc-patches@gcc.gnu.org, Jakub Jelinek 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: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg01178.txt.bz2 On Sun, Oct 18, 2009 at 9:19 PM, Michael Matz 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). =A0If non-align= ed >> automatic variables are generated you simply use unaligned moves - >> what's the problem? > > It's obvious: we don't want to generate unaligned moves. =A0That's the wh= ole > point of H.J. patches. =A0He 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 > =A0 =A0generated temporaries) > > He tries to solve this by pessimistically assuming that potentially > everything imaginable could go on stack. =A0What 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.