From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93694 invoked by alias); 24 Aug 2015 07:15:34 -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 93679 invoked by uid 89); 24 Aug 2015 07:15:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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-f180.google.com Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com) (209.85.212.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 24 Aug 2015 07:15:33 +0000 Received: by widdq5 with SMTP id dq5so40462280wid.1 for ; Mon, 24 Aug 2015 00:15:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.57.19 with SMTP id e19mr40017783wjq.152.1440400530267; Mon, 24 Aug 2015 00:15:30 -0700 (PDT) Received: by 10.28.30.131 with HTTP; Mon, 24 Aug 2015 00:15:30 -0700 (PDT) In-Reply-To: <55BF8B2B.9040001@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> Date: Mon, 24 Aug 2015 07:20: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/msg01382.txt.bz2 Hello Jason, after a longer delay the answer to your question. 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. >> 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). >>>> 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. 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. >> 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? > Jason > Kai