| Message ID | 597173047.4338388.1438379666336.JavaMail.zimbra@redhat.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
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
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>>>
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
--- 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);