http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-05 09:04:59 UTC --- Created attachment 25419 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25419 patch An incomplete patch to avoid those casts from the IL. We'd need to adjust SRA to add casts if a restrict field is scalarized and a non-restrict pointer is stored into it. It fixes this short testcase though. It is not enough though, because FRE/PRE can see through the field store and will create undesirable restrict casts: t_3->p = q_4(D); ... D.2099_6 = t_3->p; becomes t_3->p = q_4(D); ... D.2099_6 = (int * restrict) q_4(D); during fre1 (in this case it doesn't matter, as for s.p FRE can't see through the pointer and thus it doesn't have a restrict tag). So, either FRE/PRE (and whatever else) would need to give up on seeing through in these non-restrict -> restrict field cases, or it would be better instead of avoiding these casts make non-restrict -> restrict casts from user code explicit (e.g. some different kind of gimple unary assignment), treat them more carefully during optimizations (yes, it would prevent some optimizations, but hopefully restrict is used only where it actually can give more improvements from successful disambiguation) and only handle those as CAST_RESTRICT and not random other !TYPE_RESTRICT -> TYPE_RESTRICT conversions in the IL which are there just for IL consistency (we could even make such non-special !restrict -> restrict conversions useless).
