Message ID | 5631F735.2080604@mentor.com |
---|---|
State | New |
Headers | show |
On Thu, Oct 29, 2015 at 11:38 AM, Tom de Vries <Tom_deVries@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 <jakub@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. 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). Richard. > Thanks, > - Tom > >
Allow CAST_RESTRICT folding 2015-10-29 Tom de Vries <tom@codesourcery.com> * fold-const.c (fold_unary_loc): Remove folding inhibition for restrict types. --- gcc/fold-const.c | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/fold-const.c b/gcc/fold-const.c index c4be017..1cd911a 100644 --- a/gcc/fold-const.c +++ b/gcc/fold-const.c @@ -7728,7 +7728,6 @@ fold_unary_loc (location_t loc, enum tree_code code, tree type, tree op0) that this happens when X or Y is NOP_EXPR or Y is INTEGER_CST. */ if (POINTER_TYPE_P (type) && TREE_CODE (arg0) == POINTER_PLUS_EXPR - && (!TYPE_RESTRICT (type) || TYPE_RESTRICT (TREE_TYPE (arg0))) && (TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST || TREE_CODE (TREE_OPERAND (arg0, 0)) == NOP_EXPR || TREE_CODE (TREE_OPERAND (arg0, 1)) == NOP_EXPR)) -- 1.9.1