On Fri, Oct 30, 2015 at 9:58 AM, Tom de Vries <tom_devr...@mentor.com> wrote: > [ was: Re: [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279) > ] > > On 29/10/15 12:38, Richard Biener wrote: >> >> On Thu, Oct 29, 2015 at 11:38 AM, Tom de Vries <tom_devr...@mentor.com> >> wrote: >>> >>> [ quote-pasted from >>> https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00464.html >>> ] >>> >>>> CAST_RESTRICT based disambiguation unfortunately isn't reliable, >>>> e.g. to store a non-restrict pointer into a restricted field, >>>> we add a non-useless cast to restricted pointer in the gimplifier, >>>> and while we don't consider that field to have a special restrict tag >>>> because it is unsafe to do so, we unfortunately create it for the >>>> CAST_RESTRICT before that and end up with different restrict tags >>>> for the same thing. See the PR for more details. >>>> >>>> This patch turns off CAST_RESTRICT handling for now, in the future >>>> we might try to replace it by explicit CAST_RESTRICT stmts in some form, >>>> but need to solve problems with multiple inlined copies of the same >>>> function >>>> with restrict arguments or restrict variables in it and intermixed code >>>> from >>>> them (or similarly code from different non-overlapping source blocks). >>>> >>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >>>> 4.6 too? >>>> >>>> 2011-10-06 Jakub Jelinek <ja...@redhat.com> >>>> >>>> PR tree-optimization/49279 >>>> * tree-ssa-structalias.c (find_func_aliases): Don't handle >>>> CAST_RESTRICT. >>>> * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Allow >>>> restrict propagation. >>>> * tree-ssa.c (useless_type_conversion_p): Don't return false >>>> if TYPE_RESTRICT differs. >>>> >>>> * gcc.dg/tree-ssa/restrict-4.c: XFAIL. >>>> * gcc.c-torture/execute/pr49279.c: New test. >>> >>> >>> >>> Hi, >>> >>> In the patch adding support for CAST_RESTRICT ( >>> https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00176.html ) there was also >>> a >>> bit: >>> ... >>> * fold-const.c (fold_unary_loc): Don't optimize >>> POINTER_PLUS_EXPR casted to TYPE_RESTRICT pointer by >>> casting the inner pointer if it isn't TYPE_RESTRICT. >>> ... >>> which is still around. I suppose we can remove this bit as well. >>> >>> OK for trunk if bootstrap and reg-test succeeds? >> >> >> Ok. > > > Committed. > >> I think the checks on TREE_OPERAND (arg0, 1) are bogus though >> and either we should unconditionally sink the conversion or only >> if a conversion on TREE_OPERAND (arg0, 0) vanishes (I prefer the >> latter). >> > > Like this? OK for trunk if bootstrap/reg-test succeeds?
Ok with using CONVERT_EXPR_P (TREE_OPERAND (arg0, 0)) instead of an explicit NOP_EXPR check. Thanks, Richard. > Thanks, > - Tom >
