From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14746 invoked by alias); 17 Oct 2009 19:21:02 -0000 Received: (qmail 14737 invoked by uid 22791); 17 Oct 2009 19:21:01 -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; Sat, 17 Oct 2009 19:20:56 +0000 Received: by vws8 with SMTP id 8so2171262vws.0 for ; Sat, 17 Oct 2009 12:20:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.69.83 with SMTP id y19mr5922810vci.64.1255807254113; Sat, 17 Oct 2009 12:20:54 -0700 (PDT) In-Reply-To: <6dc9ffc80910171202n34b6403fm9fe90fe1af3480d5@mail.gmail.com> References: <20090806214216.GA14439@lucon.org> <20091015154823.GA15787@lucon.org> <4AD76CBA.7030204@gmail.com> <6dc9ffc80910161312o30a8b899vd5828fb8d029c94e@mail.gmail.com> <6dc9ffc80910171114k2ed87800s7a307c671a563a7d@mail.gmail.com> <84fc9c000910171151l22f64266gf95010521ca205a@mail.gmail.com> <6dc9ffc80910171202n34b6403fm9fe90fe1af3480d5@mail.gmail.com> Date: Sat, 17 Oct 2009 19:29:00 -0000 Message-ID: <84fc9c000910171220l1bb7668q7d597061ea9a5eb5@mail.gmail.com> Subject: Re: PATCH: PR target/40838: gcc shouldn't assume that the stack is aligned From: Richard Guenther To: "H.J. Lu" Cc: 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/msg01153.txt.bz2 On Sat, Oct 17, 2009 at 9:02 PM, H.J. Lu wrote: > On Sat, Oct 17, 2009 at 11:51 AM, Richard Guenther > wrote: >> On Sat, Oct 17, 2009 at 8:14 PM, H.J. Lu wrote: >>> On Fri, Oct 16, 2009 at 5:59 PM, Ian Lance Taylor wro= te: >>>> "H.J. Lu" writes: >>>> >>>>> @@ -947,6 +949,12 @@ vect_verify_datarefs_alignment (loop_vec_info lo= op_vinfo, bb_vec_info bb_vinfo) >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>>>> =A0 =A0 =A0 =A0 =A0 =A0return false; >>>>> =A0 =A0 =A0 =A0 =A0} >>>>> + >>>>> + =A0 =A0 =A0mode =3D TYPE_MODE (STMT_VINFO_VECTYPE (stmt_info)); >>>>> + =A0 =A0 =A0align =3D GET_MODE_ALIGNMENT (mode); >>>>> + =A0 =A0 =A0if (cfun->hard_stack_alignment < align) >>>>> + =A0 =A0 cfun->hard_stack_alignment =3D align; >>>>> + >>>>> =A0 =A0 =A0 =A0if (supportable_dr_alignment !=3D dr_aligned >>>>> =A0 =A0 =A0 =A0 =A0 =A0&& vect_print_dump_info (REPORT_ALIGNMENT)) >>>>> =A0 =A0 =A0 =A0 =A0fprintf (vect_dump, "Vectorizing an unaligned acce= ss."); >>>> >>>> I do not understand why this is the right place to set your new cfun >>>> field. =A0Your patch is about a misaligned stack. =A0The code you are >>>> changing here does not appear to have anything to do with a misaligned >>>> stack. =A0This code is about the correct alignment of data. =A0The data >>>> may be on the stack but it need not be. =A0If the data is on the stack, >>>> then the compiler should be able to determine the alignment available >>>> on the stack. >>> >>> The issue here is to set proper incoming stack alignment. We have >>> to do it before RTL expansion which uses this information to check >>> if stack alignment is needed. To do that, we need to know what the >>> minimum stack alignment required by hardware. We collect hard >>> stack alignment when we put variables on stack and check the alignment >>> generated by vectorizer. >> >> It's surely not the right function to do this. =A0Nor is it a proper >> interface IMHO. >> Why don't you need to check whether the access is to stack memory at all? >> >> I think you want to instead see if any user-alignment on automatic >> variables requires stack realignment. =A0Thus, wherever the vectorizer >> sets DECL_USER_ALIGN on automatic storage. >> > > RTL expansion may generate automatic variables from vectorizer > statements while vectorizer doesn't generate any automatic variables > at all. How should I handle this case? The same way you would handle spills or you would handle user code using intrinsics. I don't see how the vectorizer is special. Richard. > > -- > H.J. >