Re: PR middle-end/30017 (ICE in C++ size hook)

[Jan Hubicka <jh at suse dot cz>]

Mark,
> 
> Unfortunately, "*a = *b" is imprecise in this context.  Let's use TREE
> or RTL notation instead.  For example, you want to generate a
> MODIFY_EXPR whose LHS and RHS are both INDIRECT_EXPRs of some C++ class
> type, correct?

Basically that is what I am doing.  Actually I think in my case they are
always just the C++ classes themselves since builtins do very
conservative checks on the aliasing issues, but I guess it does not make
sense for our discussion.
> 
> That's all fine -- but there's still no reason to call the expr_size
> hook.  If the transformation was valid, then "sizeof (a)" must be the
> same as TYPE_SIZE_UNIT applied to the type of the INDIRECT_EXPR
> expression.  So, you still don't need to be call a hook to figure out
> how many bytes to copy.

We seem to be in agreement here and this is what my code (or actually
originally Jakub's code I extended) does.  I was also trying to argue
originally that it would be nice to get rid of expr_size hook in this
contextes so we are closer to frontend independence of GIMPLE.  We
however get to the expr_size hook later at RTL generation time...
> 
> The bottom line is that the hook cannot give you useful information
> because the question you're asking does not have a well-defined answer
> -- so it doesn't make sense to call the hook.
> 
> > So this is why I can't trust argument of memcpy at expansion time,
> > because it is simply not there anymore.
> 
> When you say expansion time, do you mean at the point of generating
> GIMPLE, or at the point of generating RTL?  I think you mean the latter.

Yes, generating gimple is gimplification, generation RTL is expansion at
least for me ;)
>  But, in that case, you still have the TYPE_SIZE_UNIT information from
> the MODIFY_EXPR.

There are several places in RTL's expand_assignment where explow's
expr_size is queried. My patch triggers one of these.
In fact only uses of the hook are the expr_size functions and those are
used exclusively by assignment, initialization and function calling
RTL expansion code.  So if we really can safely use TYPE_SIZE_UNIT here
(ie inline lhd_expr_size implemntation from langhooks) we can also
pretty well drop the hook entirely.
> 
> I don't understand why you want to avoid folding.  Folding is just fine.

>From your explanation I understood that you are unhappy with giving any
size to the expression, so as well unhappy about giving some definition
to *a=*b assignment, so forgiving it seemed as only real choice here.
>  The user told you how many bytes to memcpy; if the size matches the
> size of the type, then you can fold, and use an aggregate copy.  You
> just can't go back and ask the front end for how many bytes you need to
> copy again -- and you shouldn't need to do so, since the user told you
> explicitly, and since the MODIFY_EXPR you generate indicates the number
> of bytes implicitly.

OK, so I guess we need to figure out how to get rid of the expr_size
used in the RTL expansion code and move the checks somewhere earlier in
the queue?

Honza