From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59690 invoked by alias); 29 Oct 2015 15:52:17 -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 59630 invoked by uid 89); 29 Oct 2015 15:52:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 29 Oct 2015 15:52:14 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id A7E5A5441DA; Thu, 29 Oct 2015 16:52:10 +0100 (CET) Date: Thu, 29 Oct 2015 15:53:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , Eric Botcazou , GCC Patches Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151029155210.GQ5527@kam.mff.cuni.cz> References: <20151014162944.GE16672@kam.mff.cuni.cz> <1456448.Tt4DpGVrAE@polaris> <20151021215701.GA14675@atrey.karlin.mff.cuni.cz> <2210014.Qgk3pAbeYD@polaris> <20151029033922.GA52478@kam.mff.cuni.cz> <20151029150215.GA34652@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-10/txt/msg03208.txt.bz2 > On Thu, Oct 29, 2015 at 4:02 PM, Jan Hubicka wrote: > >> > >> IMHO it was always wrong/fragile for backends to look at the actual arguments to > >> decide on the calling convention. The backends should _solely_ rely on > >> gimple_call_fntype and its TYPE_ARG_TYPES here. > >> > >> Of course then there are varargs ... (not sure if we hit this here). > > > > Yep, you have varargs and K&R prototypes, so it can't work this way. > > Well, then I suppose we need to compute the ABI upfront when we gimplify > from the orginal args (like we preserve fntype). Having a separate fntype > was really meant to make us preserve the ABI throughout the GIMPLE phase... Hmm, the idea of doing some part of ABI explicitly is definitly nice (at least the implicit promotions and pass by reference bits), but storing the full lowlevel info on how to pass argument seems bit steep. You will need to preserve the RTL containers for parameters that may get non-trivial (PARALLEL) and precompute all the other information how to get data on stack. While playing with the ABi checker I was just looking into this after several years (when i was cleaning up calls.c) and calls.c basically works by computing arg_data that holds most of the info you would need (you need also return argument passing and the hidden argument for structure returns). You can check it out - it is fairly non-trivial beast plus it really holds two parallel sets of infos - tailcall and normal call (because these differ for targets with register windows). The info also depends on flags used to compile function body (such as -maccumulate-outgoing-args) To make something like this a permanent part of GIMPLE would probably need quite careful re-engineering of the APIs inventing more high-level intermediate representation to get out of the machine description. There is not realy immediate benefit from knowing how parameters are housed on stack for gimple optimizers, so perhaps just keeping the type information (after promotions) as the way to specify call conventions is more practical way to go. Honza > >> But yes, the VIEW_CONVERT "stripping" is a bit fragile and I don't remember > >> what exactly we gain from it (when not done on registers). > > > > I guess gain is really limited to Ada - there are very few cases we do VCE otherwise. > > (I think we could do more of them). We can make useless_type_conversion NOP/CONVERT > > only. That in fact makes quite a sense because those are types with gimple operations > > on it. Perhaps also VCE on vectors, but not VCE in general. > > > > Honza > >> > >> But I also don't see where we do the stripping mentioned on memory references. > >> The match.pd pattern doesn't apply to memory, only in the GENERIC path > >> which is guarded with exact type equality. So I can't see where we end up > >> stripping the V_C_E. > >> > >> There is one bogus case still in fold-const.c: > >> > >> case VIEW_CONVERT_EXPR: > >> if (TREE_CODE (op0) == MEM_REF) > >> /* ??? Bogus for aligned types. */ > >> return fold_build2_loc (loc, MEM_REF, type, > >> TREE_OPERAND (op0, 0), TREE_OPERAND (op0, 1)); > >> > >> return NULL_TREE; > >> > >> that comment is only in my local tree ... (we lose alignment info that is > >> on the original MEM_REF type which may be a smaller one). > >> > >> Richard. > >> > >> > Honza > >> >> > >> >> > >> >> * gnat.dg/discr44.adb: New test. > >> >> > >> >> -- > >> >> Eric Botcazou > >> > > >> >> -- { dg-do run } > >> >> -- { dg-options "-gnatws" } > >> >> > >> >> procedure Discr44 is > >> >> > >> >> function Ident (I : Integer) return Integer is > >> >> begin > >> >> return I; > >> >> end; > >> >> > >> >> type Int is range 1 .. 10; > >> >> > >> >> type Str is array (Int range <>) of Character; > >> >> > >> >> type Parent (D1, D2 : Int; B : Boolean) is record > >> >> S : Str (D1 .. D2); > >> >> end record; > >> >> > >> >> type Derived (D : Int) is new Parent (D1 => D, D2 => D, B => False); > >> >> > >> >> X1 : Derived (D => Int (Ident (7))); > >> >> > >> >> begin > >> >> if X1.D /= 7 then > >> >> raise Program_Error; > >> >> end if; > >> >> end; > >> >