This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] [tree-optimization/80576] Handle non-constant sizes in DSE

On 8/19/19 7:57 AM, Richard Biener wrote:

> +static tree
> +objsize_from_type (tree object)
> +{
> +  if (TREE_CODE (object) != ADDR_EXPR)
> +    return NULL_TREE;
> +
> +  tree type = TREE_TYPE (object);
> +  if (POINTER_TYPE_P (type))
> that if looks suspicious...  I'd say
>   if (!POINTER_TYPE_P (type))
>     return NULL_TREE;
> is better
Sure.  But we may not be able to use this anyway as you noted later,
depending on the type is not safe.

> +    type = TREE_TYPE (type);
> +  if (TREE_CODE (type) == ARRAY_TYPE && !array_at_struct_end_p (object))
> +    {
> array_at_struct_end_p will never return true here since you pass it
> an ADDR_EXPR...  you wanted to pass TREE_OPERAND (object, 0) here?
I think you're right.  Given this was cribbed from the tail of another
function elsewhere, I suspect that other function has the same issue.

I suspect ultimately we want to fix that other copy and drop

> Also you seem to use this info to constrain optimization when you
> might remember that types of addresses do not carry such information...
> Thus it should be "trivially" possible to write a testcase that is miscompiled
> after your patch.  I also don't see this really exercised in the
> testcases you add?
Arggh.  You're absolutely correct.  I must be blocking out that entire
discussion from last summer due to the trama :-)

If the destination is the address of a _DECL node, can we use the size
of the _DECL?

> All of them reference a static array a ...
> +           if (TREE_CODE (size) != INTEGER_CST)
> TREE_CODE (size) == SSA_NAME you want
Agreed.  Will fix.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]