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

[Jeff Law <law at redhat dot com>]

On 8/22/19 8:40 AM, Martin Sebor wrote:
> On 8/21/19 4:47 PM, Jeff Law wrote:
>> 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
>> objsize_from_type.
> 
> Is the other copy compute_objsize in builtins.c?  The function
> has a comment that says it "is intended for diagnostics a should
> not be used to influence code generation or optimization."
> I added that comment on your request, not because the function
> relies the type of objects but because it conservatively uses
> the lower bound of ranges of offsets into arrays to determine
> the minimum size.
That's the one.  What's sad here is when I copied the tail of that
routine I noted the comment.  By the time I came back to the changes
several days (or weeks?) later the issue had been totally wiped from my
working memory.

I think I can just call get_base_address on the 0th operand of the
ADDR_EXPR and if I get back a _DECL node extract its DECL_UNIT_SIZE.

Jeff