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?