From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19243 invoked by alias); 13 Jun 2011 03:18:06 -0000 Received: (qmail 19229 invoked by uid 22791); 13 Jun 2011 03:18:05 -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 qmta04.emeryville.ca.mail.comcast.net (HELO qmta04.emeryville.ca.mail.comcast.net) (76.96.30.40) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Jun 2011 03:17:50 +0000 Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta04.emeryville.ca.mail.comcast.net with comcast id vFDC1g0081Y3wxoA4FHokc; Mon, 13 Jun 2011 03:17:48 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta15.emeryville.ca.mail.comcast.net with comcast id vFHM1g0070BKwT48bFHMsG; Mon, 13 Jun 2011 03:17:22 +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: Mon, 13 Jun 2011 07:29: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/msg00960.txt.bz2 On Jun 12, 2011, at 3:55 AM, Richard Guenther wrote: > In almost all cases(*) the need for a lvalue VIEW_CONVERT_EXPR can be avo= ided > by moving the VIEW_CONVERT_EXPR to the rvalue assigned too it. Remember = that > VIEW_CONVERT_EXPR always conver the full object and are not allowed to > change sizes. >=20 > So, do you have an example? Sure, take a divmod type of instruction.[1] It has two outputs, a div and = a mod. The instruction operates on registers, and produces two completely = independent values. But really, it is a general features of the built-in m= echanism that Kenny and I are working on that some people would like to reu= se for other ports. The general feature is that one can declare any argume= nt to a built-in to be input only, output only or input/output. This nicel= y matches what I think quite of lot of machines do for assembly language se= mantics. The support isn't to match my machine, but rather to support buil= ding a port, in which 1 or more instructions have such parameters. Requiri= ng memory is a non-starter, and in fact, we already have a scheme for memor= y_operand type things for the instructions that take memory. The scheme us= ed for them is borrowed from C++, where we just declare that the built-in t= akes a reference type. This reuses most of the code paths from C++ and it = seems to work nicely. I'd be tempting to use it for register references, b= ut, in my current scheme for registers, I support data flow in, out and in/= out at the tree level and at the rtl level. We believe this is nice from a= n optimizing perspective, and probably required to get the warnings about u= sing uninitialized variables correct.