http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> 2011-10-05 09:40:58 UTC --- On Wed, 5 Oct 2011, jakub at gcc dot gnu.org wrote: > 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). I think rather than trying to remove those casts from the IL we should think if preserving restrict optimizations for inlining is really important (which is what the cast handling is for). The cast handling, compared to the existing handling of arguments and global vars, is really sensitive to optimizations to be 'correct' (see the other PR where we inline a restrict argument function twice and assign different restrict tags during PTA to the two copies and do wrong cross inlined-body optimizations). So, for correctness we should consider removing the cast handling. (My proposed fix for the other PR sofar was to assign a fake tag to every pointer so propagation can see the two pointers (with different restrict tag) are still based on each other). Richard.
