From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6432 invoked by alias); 14 Jun 2011 20:13:20 -0000 Received: (qmail 6419 invoked by uid 22791); 14 Jun 2011 20:13:17 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,TW_IV,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta01.emeryville.ca.mail.comcast.net (HELO qmta01.emeryville.ca.mail.comcast.net) (76.96.30.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Jun 2011 20:13:03 +0000 Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta01.emeryville.ca.mail.comcast.net with comcast id vvPn1g00A1zF43QA1wD16M; Tue, 14 Jun 2011 20:13:01 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta24.emeryville.ca.mail.comcast.net with comcast id vwCd1g01K0BKwT48kwCeb1; Tue, 14 Jun 2011 20:12:39 +0000 Subject: Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10)) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: Date: Tue, 14 Jun 2011 20:31:00 -0000 Cc: Richard Guenther , Jason Merrill , gcc-patches List Content-Transfer-Encoding: quoted-printable 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> To: Richard Guenther 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: 2011-06/txt/msg01106.txt.bz2 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 typ= e: mod =3D 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 woul= d be a rvalue context, but ultimately, it was an lvalue context. We discov= er 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 >=20 > { div_1, mod_2 } =3D __builtin_divmod (arg_3); >=20 > 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 =3D builtin_divmod_final (a, b); div_1 =3D s.div mod_2 =3D s.mod and generate a type { div, mod } on the fly. We expect the optimizer to ha= ndle extra moves reasonably, and we want to keep the one instruction as one= unit. > We already play tricks for sincos for example via >=20 > tem_1 =3D __builtin_cexpi (arg_2); > sin_3 =3D REALPART_EXPR ; > cos_4 =3D IMAGPART_EXPR ; >=20 > which avoids the two defs by using a single def which is then decomposed. >=20 > 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_inp= uts 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=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 (var_operand:T_ALL_DI 1)]) ;;mod=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 (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 =3D divmodu_t_v4udi (t_v4udi_1, t_v4udi_2, t_v4udi_3); The VIEW_CONVERT_EXPR looks like: unit size align 64 symtab 0 alias set -1 canonical type 0x7ffff7e8c690 pr= ecision 64 min max\ pointer_to_this reference_to_this= > unsigned V4DI size unit size align 256 symtab 0 alias set -1 canonical type 0x7ffff7f4b930 nunit= s 4 reference_to_this > arg 0 unsigned V4DI size unit size <= integer_cst 0x7ffff7e76348 32> align 256 symtab 0 alias set -1 canonical type 0x7ffff5ac3888 n= units 4> used public static unsigned V4DI defer-output file t22.c line 262 c= ol 48 size unit \ size align 256>> Hopefully, somewhere about is an example of what you wanted to see, if not,= let me know what you'd like to see.