From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 332 invoked by alias); 27 Aug 2015 10:39:23 -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 321 invoked by uid 89); 27 Aug 2015 10:39:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f179.google.com Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 27 Aug 2015 10:39:20 +0000 Received: by wijn1 with SMTP id n1so51174219wij.0 for ; Thu, 27 Aug 2015 03:39:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.57.19 with SMTP id e19mr4309705wjq.152.1440671956935; Thu, 27 Aug 2015 03:39:16 -0700 (PDT) Received: by 10.28.30.131 with HTTP; Thu, 27 Aug 2015 03:39:16 -0700 (PDT) In-Reply-To: <55DE7C55.6030207@redhat.com> 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> <55DE7C55.6030207@redhat.com> Date: Thu, 27 Aug 2015 10:54:00 -0000 Message-ID: Subject: Re: C++ delayed folding branch review From: Kai Tietz To: Jason Merrill Cc: Kai Tietz , gcc-patches List Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01683.txt.bz2 2015-08-27 4:56 GMT+02:00 Jason Merrill : > 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 gets introduced in convert.c about line 836 in function convert_to_integer_1 AFAIK. There should be the alternative solution for this issue by disallowing for PLUS/MINUS/... expressions the sinking of the cast into the expression, if dofold is false, and type has same width as inner_type, and is of vector-kind. >>>> 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. (vec) (const vector) { ... } expression can't be folded. This cast to none-const variant happens due the 'constexpr v = v + ' pattern in testcase. v is still of type vec, even if function itself is constexpr. >>>>>> 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. No other operand isn't a constant-value. See code-pattern in testcase. It is of type 'vec', which isn't constant (well, 'v' is, but constexpr doesn't know about it). The bogus error-message happens in: #1 0x00668c20 in verify_constant (t=t@entry=0xffd3cbe8, allow_non_constant=, non_constant_p=non_constant_p@entry=0xe5fa6fa, overflow_p=overflow_p@entry=0xe5fa6fb) at ../../src/gcc/cp/constexpr.c:1480 #2 0x0066c710 in cxx_eval_binary_expression (overflow_p=0xe5fa6fb, non_constant_p=0xe5fa6fa, t=0xffd3cba0, ctx=0xe5fa6fc) at ../../src/gcc/cp/constexpr.c:1620 #3 cxx_eval_constant_expression (ctx=ctx@entry=0xe5fa6fc, t=t@entry=0xffd3cba0, lval=lval@entry=false, non_constant_p=non_constant_p@entry=0xe5fa6fa, overflow_p=overflow_p@entry=0xe5fa6fb, jump_target=jump_target@entry=0x0) at ../../src/gcc/cp/constexpr.c:3491 #2 0x0066c710 in cxx_eval_binary_expression (overflow_p=0xe5fa6fb, non_constant_p=0xe5fa6fa, t=0xffd3cba0, ctx=0xe5fa6fc) at ../../src/gcc/cp/constexpr.c:1620 1620 VERIFY_CONSTANT (lhs); >> 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. Sure, but the variable 'v' is the problem, not a constant-value itself. >>>> 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. Hmm, it isn't related to a view-convert. So moving it into fold_unary_loc wouldn't solve here anything. Issue is in constexpr code, not in folding itself. > Jason > Kai