From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5665 invoked by alias); 15 Jun 2011 09:04:34 -0000 Received: (qmail 5656 invoked by uid 22791); 15 Jun 2011 09:04:32 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,TW_IV,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Jun 2011 09:04:07 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id DDA8894393; Wed, 15 Jun 2011 11:04:05 +0200 (CEST) Date: Wed, 15 Jun 2011 09:54:00 -0000 From: Richard Guenther To: Mike Stump Cc: Richard Guenther , Jason Merrill , gcc-patches List Subject: Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10)) In-Reply-To: Message-ID: References: <4DEDB98F.6010508@redhat.com> <4DEE2DCF.7020905@redhat.com> <4DEE3484.8030101@redhat.com> <4DF11FBC.3010304@redhat.com> <4DF223D4.3080700@redhat.com> <4DF22656.9050700@redhat.com> <37B61697-B4A5-49B6-87C4-AD361A86F752@comcast.net> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2011-06/txt/msg01139.txt.bz2 On Tue, 14 Jun 2011, Mike Stump wrote: > On Jun 13, 2011, at 3:57 AM, Richard Guenther wrote: > > That's not exactly an example - I can't think of how you want or need > > to use VIEW_CONVERT_EXPRs to implement said divmod instruction or why > > you would need anything special for the _argument_ of said instruction. > > Oh, I completely misunderstood your question. In my case, as I previously stated, was with a vector type that was identical, save the name of the type: > > mod = a%b > > where mod didn't have the type of the expression (a%b), so someone created the VIEW_CONVERT_EXPR on the mod. The person creating it _thought_ it would be a rvalue context, but ultimately, it was an lvalue context. We discover the lvalue/rvalue state of the expression at target_fold_builtin time. The actual code looks more like: > > __builtin_divmod (div, mod, a, b); > > In fold_builtin, we do all the processing to handle the semantics. > > > An > > instruction or call with multiple outputs would simply be something > > like > > > > { div_1, mod_2 } = __builtin_divmod (arg_3); > > > > with two SSA defs. A nice representation for the tree for { div_1, > > mod_2 } remains to be found (if it should be a single tree at all, or > > possibly multiple ones). > > At target_fold_builtin time we regenerate it as: > > s = builtin_divmod_final (a, b); > div_1 = s.div > mod_2 = s.mod > > and generate a type { div, mod } on the fly. We expect the optimizer to handle extra moves reasonably, and we want to keep the one instruction as one unit. > > > We already play tricks for sincos for example via > > > > tem_1 = __builtin_cexpi (arg_2); > > sin_3 = REALPART_EXPR ; > > cos_4 = IMAGPART_EXPR ; > > > > which avoids the two defs by using a single def which is then decomposed. > > > > So, can you elaborate a bit more on what you want to do with special > > argument kinds? Elaborate with an actual example, not words. > > We support tagging any parameter to a builtin as define_outputs, define_inputs or define_in_outs in a part of the .md file that describes the builtins for the machine, the actual divmod builtin for example is: > > (define_builtin "divmod" "divmod_" > [ > (define_outputs [(var_operand:T_ALL_DI 0) ;;dividend > (var_operand:T_ALL_DI 1)]) ;;mod > (define_inputs [(var_operand:T_ALL_DI 2) > (var_operand:T_ALL_DI 3)]) > (define_rtl_pattern "divmod4" [0 1 2 3]) > (attributes [pure]) > ] > ) > > that's the actual code. The testcase looks like: > > t_v4udi_0 = divmodu_t_v4udi (t_v4udi_1, t_v4udi_2, t_v4udi_3); I see. So it's the C side of the representation that needs the special operands. > The VIEW_CONVERT_EXPR looks like: > > type type size > unit size > align 64 symtab 0 alias set -1 canonical type 0x7ffff7e8c690 precision 64 min max\ > > pointer_to_this reference_to_this > > unsigned V4DI > size > unit size > align 256 symtab 0 alias set -1 canonical type 0x7ffff7f4b930 nunits 4 reference_to_this 540>> > > arg 0 type > unsigned V4DI size unit size > align 256 symtab 0 alias set -1 canonical type 0x7ffff5ac3888 nunits 4> > used public static unsigned V4DI defer-output file t22.c line 262 col 48 size unit \ > size > align 256>> This VIEW_CONVERT_EXPR looks useless - in fact useless_type_conversion_p will tell you that, so you can omit it. Richard.