> Passes ought to distinguish GIMPLE values from GIMPLE invariants
> according to context.
Looks like someone already ran into the problem. In tree-ssa-ccp.c:
/* The regular is_gimple_min_invariant does a shallow test of the object.
It assumes that full gimplification has happened, or will ha
On 7/5/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> We never insert expressions for FRE, and the replacement we do will
> only replace the entire RHS with an SSA_NAME or a constant.
The problem is precisely that the expression is deemed a constant:
/* Setting value numbers to consta
> We never insert expressions for FRE, and the replacement we do will
> only replace the entire RHS with an SSA_NAME or a constant.
The problem is precisely that the expression is deemed a constant:
/* Setting value numbers to constants will occasionally
screw up phi congru
On 7/5/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Note that TREE_INVARIANT is not going to be useful in an IPA world
> anyway for these users, if it really means that different calls to the
> function could produce different results.
We could test TREE_CONSTANT instead and this would be enou
> GNU C has it too:
Yes, but in that case, it's always the same for every reference to the same
type. For GENERIC, that means it can indeed be taken from the type every
time, but the issue is gimplification. The Ada case is harder because
you not only have to deal with gimplification, but that t
> Can you please, again, explain why we even have this wasting space in
> all the component_ref's?
>
> tree.def simply says " Operand 2, if present, is the value of
> DECL_FIELD_OFFSET, measured
>in units of DECL_OFFSET_ALIGN / BITS_PER_UNIT."
>
> It doesn't say why this can't be computed o
On 7/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
The same reason why we have operands 3 and 4 for ARRAY_REFs. Ada (I believe
it's only ada right now) has types that have their offsets computed at
compile-time, so
we put gimplified values of this stuff there if it doesn't match what
we can
On 7/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 7/4/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Also, we need to update the GIMPLE grammar so that ARRAY_REF and
> > ARRAY_RANGE_REF take the appropriate values:
>
> A minor comment is that operand 2 of COMPONENT_REF needs the same hand
> Passes ought to distinguish GIMPLE values from GIMPLE invariants
> according to context. As this test case shows, a GIMPLE invariant is
> not always the right value to replace as it cannot be used as a valid
> ARRAY_REF index.
OK, but the replacement is not made by FRE itself, but by fold:
/*
> Note that TREE_INVARIANT is not going to be useful in an IPA world
> anyway for these users, if it really means that different calls to the
> function could produce different results.
We could test TREE_CONSTANT instead and this would be enough to restore Ada
bootstrap. But of course the under
On 7/4/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Also, we need to update the GIMPLE grammar so that ARRAY_REF and
> ARRAY_RANGE_REF take the appropriate values:
A minor comment is that operand 2 of COMPONENT_REF needs the same handling.
Can you please, again, explain why we even have th
> Also, we need to update the GIMPLE grammar so that ARRAY_REF and
> ARRAY_RANGE_REF take the appropriate values:
A minor comment is that operand 2 of COMPONENT_REF needs the same handling.
On 7/4/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
On 7/4/07 6:24 PM, Eric Botcazou wrote:
>> The problem is that in GIMPLE we only allow TREE_INVARIANT as a gimple
>> value for ADDR_EXPRs. We still require a TREE_CONSTANT as an array
>> index. So, ARRAY[TREE_INVARIANT] is not valid GIMPLE.
>
On 7/4/07 6:24 PM, Eric Botcazou wrote:
>> The problem is that in GIMPLE we only allow TREE_INVARIANT as a gimple
>> value for ADDR_EXPRs. We still require a TREE_CONSTANT as an array
>> index. So, ARRAY[TREE_INVARIANT] is not valid GIMPLE.
>
> OK, my understanding is that is_gimple_min_invaria
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Ok. So either we want to disallow invariant addresses as gimple value
> altogether or
> do more elaborate checks, to rule out such bogus cases. At least the
> transformation
> PRE is doing doesn't make sense -- and I know other optimization
> The problem is that in GIMPLE we only allow TREE_INVARIANT as a gimple
> value for ADDR_EXPRs. We still require a TREE_CONSTANT as an array
> index. So, ARRAY[TREE_INVARIANT] is not valid GIMPLE.
OK, my understanding is that is_gimple_min_invariant as currently written is
correct as "non-rec
> It is a formal predicate of the GIMPLE grammar. But there is an
> inconsistency now. I don't think we want to allow min-invariant as
> ARRAY_REF indexes because this would allow things like
>
> &a[&b[3]]
>
> which is too gross for words. So, the grammar should be updated to
> include inv
On 7/4/07 5:29 AM, Eric Botcazou wrote:
> /* Make sure result is not a complex expression consiting
> of operators of operators (IE (a + b) + (a + c))
> Otherwise, we will end up with unbounded expressions if
> fold does anything at all. */
> if (result)
> {
> if (is_
> Sure, but CONST isn't specified.
OK, but if it's a formal predicate you cannot do what you want because of the
rest of the grammar that is "implemented" by the GIMPLE verifier.
For example &A[C + 1] and &A[C], where A is static and C is a constant
identifier, have the same degree of constness
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Ok. So either we want to disallow invariant addresses as gimple value
> altogether or
> do more elaborate checks, to rule out such bogus cases. At least the
> transformation
> PRE is doing doesn't make sense -- and I know other optimization
> Ok. So either we want to disallow invariant addresses as gimple value
> altogether or
> do more elaborate checks, to rule out such bogus cases. At least the
> transformation
> PRE is doing doesn't make sense -- and I know other optimization passes
> that treat is_gimple_min_invariant() values a
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> This is invalid gimple.
Right, but nevertheless is_gimple_val.
> Can you figure our why we don't gimplify this to
>
> tmp_1 = MAX_EXPR ;
> tmp_2 = ()tmp_1;
> tmp_3 = tmp_2 + 1;
> &p_name_buffer[tmp3]
Because there is no code to do it. If I
> This is invalid gimple.
Right, but nevertheless is_gimple_val.
> Can you figure our why we don't gimplify this to
>
> tmp_1 = MAX_EXPR ;
> tmp_2 = ()tmp_1;
> tmp_3 = tmp_2 + 1;
> &p_name_buffer[tmp3]
Because there is no code to do it. If I add it:
Index: tree-ssa-pre.c
=
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
Ada bootstrap has been broken by the SCC value numbering patch too (this is PR
tree-optimization/32589) but this might be due to a latent problem.
In the FRE dump:
RHS &p__name_buffer[1]{lb: 1 sz: 1} + n_32 simplified to
&p__name_buffer[() MAX
Ada bootstrap has been broken by the SCC value numbering patch too (this is PR
tree-optimization/32589) but this might be due to a latent problem.
In the FRE dump:
RHS &p__name_buffer[1]{lb: 1 sz: 1} + n_32 simplified to
&p__name_buffer[() MAX_EXPR + 1]{lb: 1 sz:
1} has constants 0
and the l
25 matches
Mail list logo
