From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92538 invoked by alias); 27 Aug 2015 02:56:28 -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 92515 invoked by uid 89); 27 Aug 2015 02:56:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 27 Aug 2015 02:56:26 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 91679341ACA; Thu, 27 Aug 2015 02:56:24 +0000 (UTC) Received: from [10.10.116.36] (ovpn-116-36.rdu2.redhat.com [10.10.116.36]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7R2uLts014178; Wed, 26 Aug 2015 22:56:22 -0400 Subject: Re: C++ delayed folding branch review To: Kai Tietz References: <557A5214.7060106@redhat.com> <55B911DD.30105@redhat.com> <55BA5667.9040200@redhat.com> <55BAACF9.7040707@redhat.com> <597173047.4338388.1438379666336.JavaMail.zimbra@redhat.com> <55BEE4CE.9070706@redhat.com> <55BF8B2B.9040001@redhat.com> Cc: Kai Tietz , gcc-patches List From: Jason Merrill Message-ID: <55DE7C55.6030207@redhat.com> Date: Thu, 27 Aug 2015 02:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-08/txt/msg01661.txt.bz2 On 08/24/2015 03:15 AM, Kai Tietz wrote: > 2015-08-03 17:39 GMT+02:00 Jason Merrill : >> On 08/03/2015 05:42 AM, Kai Tietz wrote: >>> 2015-08-03 5:49 GMT+02:00 Jason Merrill : >>>> On 07/31/2015 05:54 PM, Kai Tietz wrote: >>>>> >>>>> The "STRIP_NOPS-requirement in 'reduced_constant_expression_p'" I could >>>>> remove, but for one case in constexpr. Without folding we don't do >>>>> type-sinking/raising. >>>> >>>> Right. >>>> >>>>> So binary/unary operations might be containing cast, which were in the >>>>> past unexpected. >>>> >>>> Why aren't the casts folded away? >>> >>> On such cast constructs, as for this vector-sample, we can't fold away >> >> Which testcase is this? > > It is the g++.dg/ext/vector20.C testcase. IIRC I mentioned this > testcase already earlier as reference, but I might be wrong here. I don't see any casts in that testcase. So the compiler is introducing introducing conversions back and forth between const and non-const, then? I suppose it doesn't so much matter where they come from, they should be folded away regardless. >>> the cast chain. The difference here to none-delayed-folding branch is >>> that the cast isn't moved out of the plus-expr. What we see now is >>> (plus ((vec) (const vector ...) { .... }), ...). Before we had (vec) >>> (plus (const vector ...) { ... }). >> >> How could a PLUS_EXPR be considered a reduced constant, regardless of where >> the cast is? > > Of course it is just possible to sink out a cast from PLUS_EXPR, in > pretty few circumstance (eg. on constants if both types just differ in > const-attribute, if conversion is no view-convert). I don't understand how this is an answer to my question. >>>>> On verify_constant we check by reduced_constant_expression_p, if value is >>>>> a constant. We don't handle here, that NOP_EXPRs are something we want to >>>>> look through here, as it doesn't change anything if this is a constant, or >>>>> not. >>>> >>>> NOPs around constants should have been folded away by the time we get >>>> there. >>> >>> Not in this cases, as the we actually have here a switch from const to >>> none-const. So there is an attribute-change, which we can't ignore in >>> general. >> >> I wasn't suggesting we ignore it, we should be able to change the type of >> the vector_cst. > > Well, the vector_cst we can change type, but this wouldn't help > AFAICS. As there is still one cast surviving within PLUS_EXPR for the > other operand. Isn't the other operand also constant? In constexpr evaluation, either we're dealing with a bunch of constants, in which case we should be folding things fully, including conversions between const and non-const, or we don't care. > So the way to solve it would be to move such conversion out of the > expression. For integer-scalars we do this, and for some > floating-points too. So it might be something we don't handle for > operations with vector-type. We don't need to worry about that in constexpr evaluation, since we only care about constant operands. >>> But I agree that for constexpr's we could special case cast >>> from const to none-const (as required in expressions like const vec v >>> = v + 1). >> >> Right. But really this should happen in convert.c, it shouldn't be specific >> to C++. > > Hmm, maybe. But isn't one of our different goals to move such > implicit code-modification to match.pd instead? Folding const into a constant is hardly code modification. But perhaps it should go into fold_unary_loc:VIEW_CONVERT_EXPR rather than into convert.c. Jason