From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91470 invoked by alias); 30 Oct 2015 08:56:57 -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 91456 invoked by uid 89); 30 Oct 2015 08:56:56 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f178.google.com Received: from mail-yk0-f178.google.com (HELO mail-yk0-f178.google.com) (209.85.160.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 30 Oct 2015 08:56:55 +0000 Received: by ykdr3 with SMTP id r3so69039517ykd.1 for ; Fri, 30 Oct 2015 01:56:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.155.130 with SMTP id s124mr5270417ywg.68.1446195413558; Fri, 30 Oct 2015 01:56:53 -0700 (PDT) Received: by 10.37.117.136 with HTTP; Fri, 30 Oct 2015 01:56:53 -0700 (PDT) In-Reply-To: <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> <20151029155210.GQ5527@kam.mff.cuni.cz> Date: Fri, 30 Oct 2015 08:57:00 -0000 Message-ID: Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p From: Richard Biener To: Jan Hubicka Cc: Eric Botcazou , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg03326.txt.bz2 On Thu, Oct 29, 2015 at 4:52 PM, Jan Hubicka wrote: >> 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. Yeah, I suppose we'd need to either build a new function type for each variadic call then or somehow represent 'fntype' differently (note that function attributes also need to be preserved). Richard. > 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; >> >> >