Hi, On Mon, 13 Nov 2017, Richard Biener wrote:
> The main concern here is that GIMPLE is not very well defined for > aggregate copies and that gimple-fold.c happily optimizes > memcpy (&a, &b, sizeof (a)) into a = b; What you missed to mention is that we then discussed about rectifying this situation by defining GIMPLE more precisely :) Effectively an aggregate assignment in GIMPLE (right now) is always defined to be a dumb block copy. We need a way to describe a member-wise copy as well. That can either be a flag on the statement or implicit by the alias type (i.e. block copies always need the ref-all alias type, all others would be member-wise copies). Then a user-written memcpy can only be rewritten into a member-wise assignment when the types contain no padding, and SRA can only look through member-wise assignments when it doesn't see all accesses to the destination (when it does then it can look also through block copies). Then this patch can be restricted to the member-wise assignments (which still helps imagemagick as the struct in question doesn't contain padding IIRC). That, or we must dumb down SRA quite much, which I don't think would be a good idea. (I'm not sure if your example would be really valid C as it changes the dynamic type of a statically typed declaration; but OTOH we shouldn't care, as in GIMPLE the example should of course be expressible) Ciao, Michael.
