https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 22 Feb 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 > > --- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Yeah, I was worried about partial ints. Or it could be punt if TYPE_MODEs are > different and at least one of them is BLKmode. Well, then you can also check whether one mode is BLKmode. Btw, I think forwprop is lucky if it really changes _2 = VIEW_CONVERT_EXPR<uint256_t>(x); to _2 = (uint256_t) x_1(D); because match on its own would create _2 = (uint256_t) x; which would be invalid GIMPLE. So are you sure it's not update-address-taken first rewriting x to a register? For 'foo' I see x becomes a register already during into-SSA so another fix might be to re-consider and make x a non-register because of that V_C_E? (and hopefully the match pattern would then not be applied, but I'm not 100% sure on that) In principle there's nothing wrong about the transform it's the use of uint256_t that makes this problematic. So maybe we should bite the bullet and try the memcpy folding fix even at this stage ...
