diff mbox

C++ delayed folding branch review

Message ID 597173047.4338388.1438379666336.JavaMail.zimbra@redhat.com
State New
Headers show

Commit Message

Kai Tietz July 31, 2015, 9:54 p.m. UTC
----- Urspr√ľngliche Mail -----
> On 07/30/2015 05:00 PM, Kai Tietz wrote:
> > 2015-07-30 18:52 GMT+02:00 Jason Merrill <jason@redhat.com>:
> >> On 07/29/2015 06:56 PM, Kai Tietz wrote:
> >>>>>>>>>>> @@ -13078,6 +13042,8 @@ build_enumerator (tree name, tree value,
> >>>>>>>>>>> tree
> >>>>>>>>>>> enumtype, tree attributes,
> >>>>>>>>>>>        if (value)
> >>>>>>>>>>>          STRIP_TYPE_NOPS (value);
> >>>>>>>>>>>
> >>>>>>>>>>> +  if (value)
> >>>>>>>>>>> +    value = cp_try_fold_to_constant (value);
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Again, this is unnecessary because we call cxx_constant_value
> >>>>>>>>>> below.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> See nops, and other unary-operations we want to reduce here to real
> >>>>>>>>> constant value ...
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> The cxx_constant_value call below will deal with them.
> >>>>>>>
> >>>>>>>
> >>>>>>> Likewise for grokbitfield.
> >>>>>>
> >>>>>>
> >>>>>> Hmm, AFAIR we don't call cxx_constant_value in all code-paths.  But I
> >>>>>> will look into it, and come back to you on it.
> >>>>>
> >>>>>
> >>>>> I am still on it ...  first did the other points
> >>>>
> >>>>
> >>>> Looks like this hasn't changed.
> >>>
> >>>
> >>> Yes, for grokbitfield current version uses fold_simple for witdth.  So
> >>> just expressions based on constants getting reduced to short form.  In
> >>> grokbitfield I don't see invocation of cxx_constant_value.  So how can
> >>> we be sure that width is reduced to integer-cst?
> >>
> >>
> >> We call cxx_constant_value on bit-field widths in check_bitfield_decl.
> >
> > Hmm, ok.  But I don't see that this function gets called in context of
> > grokbitfield, after we set DECL_INITIAL.
> 
> Nope, it's called later on as part of finish_struct.
> 

Ok, adjusted.

> > By removing this folding here, we get new failures in
> > g++.dg/warn/overflow-warn-1.C testcase:
> > New errors are at lin 32 that 'bif-foeld 's::<anonymous>' width not an
> > integer constant'
> > and at same line ''(1 / 0) is not a constant expression'.  Those
> > message don't look wrong.
> >
> > The testcase next to this 'overflow-warn-3.C and overflow-warn-4.C'
> > failing in the same manner for (1 / 0) case.  But there are no other
> > regressions in g++.dg & libstdc++
> >
> > Shall I extend the testcases for this message?
> 
> Please.

Done.
 
> >>>>>>>>>>> @@ -1947,6 +1947,8 @@ build_complex (tree type, tree real, tree
> >>>>>>>>>>> imag)
> >>>>>>>>>>>      {
> >>>>>>>>>>>        tree t = make_node (COMPLEX_CST);
> >>>>>>>>>>>
> >>>>>>>>>>> +  real = fold (real);
> >>>>>>>>>>> +  imag = fold (imag);
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I still think this is wrong.  The arguments should be sufficiently
> >>>>>>>>>> folded.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> As we don't fold unary-operators on constants, we need to fold it
> >>>>>>>>> at
> >>>>>>>>> some place.  AFAICS is the C++ FE not calling directly
> >>>>>>>>> build_complex.
> >>>>>>>>> So this place was the easiest way to avoid issues with things like
> >>>>>>>>> '-'
> >>>>>>>>> '1' etc.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Is this because of the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>          value = build_complex (NULL_TREE, convert (const_type,
> >>>>>>>>>
> >>>>>>>>> integer_zero_node),
> >>>>>>>>> value);
> >>>>>>
> >>>>>>
> >>>>>> Might be.  This should be indeed a 'fold_convert', isn't it?
> >>>>
> >>>>
> >>>> Yes.
> >>>
> >>>
> >>> Applied modification to it.
> >>
> >>
> >> So can we remove the fold in build_complex now?
> 

Yes. Done.

> 
> >>>>>>>> in interpret_float?  I think "convert" definitely needs to do some
> >>>>>>>> folding, since it's called from middle-end code that expects that.
> >>>>>>>
> >>>>>>>
> >>>>>>> I remember talking about "convert" doing some folding (and cp_convert
> >>>>>>> not) in our 1:1 last week.
> >>>>>>
> >>>>>>
> >>>>>> Can't remember that.  I know that we were talking about the difference
> >>>>>> of convert and fold_convert.  convert can be used on C++ specifics,
> >>>>>> but fold_convert is something shared with ME.
> >>>>
> >>>>
> >>>> convert is called from the ME, which sometimes expects folding.
> >>>>
> >>>>>> So first 'fold_convert'
> >>>>>> isn't the same as 'fold (convert ())'.
> >>>>>> I don't find places we invoke convert () in ME.  We have some calls in
> >>>>>> convert.c (see convert_to_integer, convert_to_integer_nofold, and
> >>>>>> convert_to_real), which all used in AST only AFAICS.
> >>>>
> >>>>
> >>>> I was thinking of convert.c and fold-const.c to be part of the ME, since
> >>>> they are language-independent.  But I guess other people think of the ME
> >>>> starting with gimple.
> >>>>
> >>>> And it looks like the only language-independent uses of convert are in
> >>>> c-family; I guess many of them should change to fold_convert.
> >>>
> >>>
> >>> Hmm, in context of this work? Or is this more a general point about
> >>> future
> >>> work?
> >>
> >>
> >> In the context of this work, if they are introducing problematic NOPs.
> >
> > Ok, I will take a closer look to convert () usage in c-family/.  By
> > quick looking this seems to be the only place for now we needed to
> > change.
> >
> >>>>>>>>>>> @@ -5080,6 +5081,7 @@ output_constructor_bitfield (oc_local_state
> >>>>>>>>>>> *local,
> >>>>>>>>>>> unsigned int bit_offset)
> >>>>>>>>>>>        while (TREE_CODE (local->val) == VIEW_CONVERT_EXPR
> >>>>>>>>>>>              || TREE_CODE (local->val) == NON_LVALUE_EXPR)
> >>>>>>>>>>>          local->val = TREE_OPERAND (local->val, 0);
> >>>>>>>>>>> +  local->val = fold (local->val);
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Likewise.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> As soon as we can be sure that values getting fully_folded, or at
> >>>>>>>>> least folded for constants, we should be able to remove this.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Yep, they need to be folded before we get here.
> >>>
> >>>
> >>> I didn't come to remove this line for testing.  As we fold now for
> >>> initializers more early, and cp_fold supports constructors, it could
> >>> be that we don't need this anymore.  It is on my pile.
> >>
> >>
> >>> That fold is still required.  By removing it, I saw boostrap issue due
> >>> 'invalid initializer'.
> >>
> >>
> >> That indicates a folding problem earlier on, that will cause some
> >> initialization that should be performed at compile time to happen at run
> >> time instead.
> >>
> >> Please investigate the bootstrap issue further.
> >
> > Yes, I do. I assume it is related to 'store_init_value'.  For cases
> > decl_maybe_constant_var_p() is true, or decl is a static, we are
> > calling maybe_constant_init on the value, but for other cases we don't
> > simplify value. (Btw this might be related to the
> > STRIP_NOPS-requirement in 'reduced_constant_expression_p').  So by
> > adding the following hunk it seems to work (still need to verify)
> >
> > Index: typeck2.c
> > ===================================================================
> > --- typeck2.c   (Revision 226401)
> > +++ typeck2.c   (Arbeitskopie)
> > @@ -833,6 +833,8 @@ store_init_value (tree decl, tree init, vec<tree,
> >         DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl) = const_init;
> >         TREE_CONSTANT (decl) = const_init && decl_maybe_constant_var_p
> >         (decl);
> >       }
> > +  else
> > +    value = fold_simple (value);
> >
> >     if (cxx_dialect >= cxx14 && CLASS_TYPE_P (strip_array_types (type)))
> >       /* Handle aggregate NSDMI in non-constant initializers, too.  */
> 
> I guess we want to extend the code for handling statics and constants to
> also handle the case where the initializer is a CONSTRUCTOR.  And also
> fold individual elements in split_nonconstant_init.

Yes, I added a general full folding to store_init_value, and to split_nonconstant_init a folding to CONSTRUCTOR handling for RECORD_TYPES, etc.  By this I was able to remove the fold from varasm.c's output-function, too.
The invocation in split_nonconstant_init might not be necessary, but there are other callers then store_init_value.  So for them folding in those cases might be still benifitial.


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.  So binary/unary operations might be containing cast, which were in the past unexpected.  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.
So I suggest following patch, so we are able to remove the STRIP_NOPS from reduced_constant_expression_p.



Regards,
Kai
 
> Jason
> 
>

Comments

Jason Merrill Aug. 3, 2015, 3:49 a.m. UTC | #1
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 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.

Jason
Kai Tietz Aug. 3, 2015, 9:42 a.m. UTC | #2
2015-08-03 5:49 GMT+02:00 Jason Merrill <jason@redhat.com>:
> 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
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 ...) { ... }).

>> 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.  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).

> Jason
>

Kai
Jason Merrill Aug. 3, 2015, 3:39 p.m. UTC | #3
On 08/03/2015 05:42 AM, Kai Tietz wrote:
> 2015-08-03 5:49 GMT+02:00 Jason Merrill <jason@redhat.com>:
>> 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?

> 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?

>>> 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.

> 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++.

Jason
Kai Tietz Aug. 24, 2015, 7:15 a.m. UTC | #4
Hello Jason,

after a longer delay the answer to your question.

2015-08-03 17:39 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>
>> 2015-08-03 5:49 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>
>>> 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
Jason Merrill Aug. 27, 2015, 2:56 a.m. UTC | #5
On 08/24/2015 03:15 AM, Kai Tietz wrote:
> 2015-08-03 17:39 GMT+02:00 Jason Merrill <jason@redhat.com>:
>> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>> 2015-08-03 5:49 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>> 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
Kai Tietz Aug. 27, 2015, 10:39 a.m. UTC | #6
2015-08-27 4:56 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 08/24/2015 03:15 AM, Kai Tietz wrote:
>>
>> 2015-08-03 17:39 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>
>>> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>>>
>>>> 2015-08-03 5:49 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>>
>>>>> 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 +
<constant-value>' 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=<optimized out>,
    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
Jason Merrill Aug. 27, 2015, 1:27 p.m. UTC | #7
On 08/27/2015 06:39 AM, Kai Tietz wrote:
> 2015-08-27 4:56 GMT+02:00 Jason Merrill <jason@redhat.com>:
>> On 08/24/2015 03:15 AM, Kai Tietz wrote:
>>> 2015-08-03 17:39 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>>>> 2015-08-03 5:49 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>>> 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.

Why would we be calling convert_to_integer for conversions between 
vector types?

>>>>> 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.

It currently isn't folded, but why can't we change that?

> This cast to
> none-const variant happens due the 'constexpr v = v +
> <constant-value>' pattern in testcase.  v is still of type vec, even
> if function itself is constexpr.

I don't see that pattern in the testcase:

typedef long vec __attribute__((vector_size (2 * sizeof (long))));
constexpr vec v = { 3, 4 };
constexpr vec s = v + v;
constexpr vec w = __builtin_shuffle (v, v);

If we have v + constant-value, that's because we pulled out the constant 
value of one of the v's, which we ought to be doing for both of them.

>>>>>>> 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).

What do you mean, "constexpr doesn't know about it"?

>>> 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.

What TREE_CODE does the conversion (vec) (const vector) { ... } use?

Jason
Kai Tietz Aug. 27, 2015, 1:38 p.m. UTC | #8
2015-08-27 15:27 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 08/27/2015 06:39 AM, Kai Tietz wrote:
>>
>> 2015-08-27 4:56 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>
>>> On 08/24/2015 03:15 AM, Kai Tietz wrote:
>>>>
>>>> 2015-08-03 17:39 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>>
>>>>> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>>>>>
>>>>>> 2015-08-03 5:49 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>>>>
>>>>>>> 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.
>
>
> Why would we be calling convert_to_integer for conversions between vector
> types?
>
>>>>>> 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.
>
>
> It currently isn't folded, but why can't we change that?
>
>> This cast to
>> none-const variant happens due the 'constexpr v = v +
>> <constant-value>' pattern in testcase.  v is still of type vec, even
>> if function itself is constexpr.
>
>
> I don't see that pattern in the testcase:
>
> typedef long vec __attribute__((vector_size (2 * sizeof (long))));
> constexpr vec v = { 3, 4 };
> constexpr vec s = v + v;
> constexpr vec w = __builtin_shuffle (v, v);
>
> If we have v + constant-value, that's because we pulled out the constant
> value of one of the v's, which we ought to be doing for both of them.
>
>>>>>>>> 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).
>
>
> What do you mean, "constexpr doesn't know about it"?
>
>>>> 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.
>
>
> What TREE_CODE does the conversion (vec) (const vector) { ... } use?

The tree code is a NOP_EXPR.

(gdb) call debug_tree (lhs)
 <nop_expr 0xffd3cbe8
    type <vector_type 0xffd4a140 vec
        type <integer_type 0xffcd04e0 long int public SI
            size <integer_cst 0xffde0ff0 constant 32>
            unit size <integer_cst 0xffde1008 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0xffcd04e0
precision 32 min <integer_cst 0xffde1038 -2147483648> max <integer_cst
0xffde1050 2147483647>
            pointer_to_this <pointer_type 0xffcd3f00>>
        V2SI
        size <integer_cst 0xffde0db0 constant 64>
        unit size <integer_cst 0xffde0dc8 constant 8>
        align 64 symtab 0 alias set -1 canonical type 0xffd4a0e0 nunits 2>
    constant
    arg 0 <vector_cst 0xffd3cb40
        type <vector_type 0xffd4a1a0 vec type <integer_type 0xffcd04e0 long int>
            readonly V2SI size <integer_cst 0xffde0db0 64> unit size
<integer_cst 0xffde0dc8 8>
            align 64 symtab 0 alias set -1 canonical type 0xffd4a200 nunits 2>
        constant
        elt0:  <integer_cst 0xffd3cb10 constant 3>
        elt1:  <integer_cst 0xffd3cb28 constant 4>>>
Jason Merrill Aug. 28, 2015, 2:08 a.m. UTC | #9
On 08/27/2015 09:38 AM, Kai Tietz wrote:
> 2015-08-27 15:27 GMT+02:00 Jason Merrill <jason@redhat.com>:
>> On 08/27/2015 06:39 AM, Kai Tietz wrote:
>>>
>>> 2015-08-27 4:56 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>
>>>> On 08/24/2015 03:15 AM, Kai Tietz wrote:
>>>>>
>>>>> 2015-08-03 17:39 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>>>
>>>>>> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>>>>>>
>>>>>>> 2015-08-03 5:49 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>>>>>
>>>>>>>> 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.
>>
>>
>> Why would we be calling convert_to_integer for conversions between vector
>> types?
>>
>>>>>>> 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.
>>
>>
>> It currently isn't folded, but why can't we change that?
>>
>>> This cast to
>>> none-const variant happens due the 'constexpr v = v +
>>> <constant-value>' pattern in testcase.  v is still of type vec, even
>>> if function itself is constexpr.
>>
>>
>> I don't see that pattern in the testcase:
>>
>> typedef long vec __attribute__((vector_size (2 * sizeof (long))));
>> constexpr vec v = { 3, 4 };
>> constexpr vec s = v + v;
>> constexpr vec w = __builtin_shuffle (v, v);
>>
>> If we have v + constant-value, that's because we pulled out the constant
>> value of one of the v's, which we ought to be doing for both of them.
>>
>>>>>>>>> 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).
>>
>>
>> What do you mean, "constexpr doesn't know about it"?
>>
>>>>> 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.
>>
>>
>> What TREE_CODE does the conversion (vec) (const vector) { ... } use?
>
> The tree code is a NOP_EXPR.

That's probably a bug, seeing as fold_convert and convert_to_vector use 
VIEW_CONVERT_EXPR.

Jason
diff mbox

Patch

--- constexpr.c	(revision 226452)
+++ constexpr.c	(working copy)
@@ -1441,8 +1441,6 @@  cxx_eval_call_expression (const constexpr_ctx *ctx
 bool
 reduced_constant_expression_p (tree t)
 {
-  /* Make sure we remove useless initial NOP_EXPRs.  */
-  STRIP_NOPS (t);
   switch (TREE_CODE (t))
     {
     case PTRMEM_CST:
@@ -1476,7 +1474,10 @@  static bool
 verify_constant (tree t, bool allow_non_constant, bool *non_constant_p,
 		 bool *overflow_p)
 {
-  if (!*non_constant_p && !reduced_constant_expression_p (t))
+  tree rde = t;
+
+  STRIP_NOPS (rde);
+  if (!*non_constant_p && !reduced_constant_expression_p (rde))
     {
       if (!allow_non_constant)
 	error ("%q+E is not a constant expression", t);