2015-08-27 15:27 GMT+02:00 Jason Merrill <ja...@redhat.com>:
> On 08/27/2015 06:39 AM, Kai Tietz wrote:
>>
>> 2015-08-27 4:56 GMT+02:00 Jason Merrill <ja...@redhat.com>:
>>>
>>> On 08/24/2015 03:15 AM, Kai Tietz wrote:
>>>>
>>>> 2015-08-03 17:39 GMT+02:00 Jason Merrill <ja...@redhat.com>:
>>>>>
>>>>> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>>>>>
>>>>>> 2015-08-03 5:49 GMT+02:00 Jason Merrill <ja...@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>>>
