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

[Mark Mitchell <mark at codesourcery dot com>]

Jan Hubicka wrote:

> The layout of the class with such a virtual inheritance is that the class B
> has (4 byte) offset set to class A.  Normally they are laid out in a way
> so B is next to representation of A, but with multiple inheritance the
> offset might point to other already existing instance of A within the
> bigger object.  Right?

Right.

> memcpy (&a,&b,sizeof (a));
> 
> and I want to fold it into:
> 
> *a=*b;
> 
> if all the preconditions (a and b are aligned, not overlapping, don't
> have aliasing issues and size match) are met.

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?

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.

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.
 But, in that case, you still have the TYPE_SIZE_UNIT information from
the MODIFY_EXPR.

> At folding time I need to compare argument of memcpy with the size of
> the aggregate being copied, if it is defined.
> 
> So now the question is if we can define the size of aggregate in this
> case (it would be nice if it was simply the largest offest field we can
> access) to allow the folding in that particular C++ case or simply find
> way to express backend the fact that "this size is undefined for some
> reason, don't try to fold here" probably by making expr_size to return
> NULL instead of ICEying and teaching builtins.c to query expr_size hook.

I don't understand why you want to avoid folding.  Folding is just fine.
 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.

> I think it would be nice to define size of class B to 4.

Yes, Jason and I have discussed this, and it would be nice, but it's
real work.  And, even when you're done it still doesn't make sense for
the back end to be calling the expr_size hook in these cases.  There's
no right answer to "how many bytes does a B* point to".  If the back end
ever needs that information, we're hosed.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713