| Message ID | 56333152.7040403@mentor.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Oct 30, 2015 at 9:58 AM, Tom de Vries <Tom_deVries@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_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. > > > 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 >
Allow more pointer-plus folding 2015-10-30 Tom de Vries <tom@codesourcery.com> * fold-const.c (fold_unary_loc): Allow more POINTER_PLUS_EXPR folding. --- gcc/fold-const.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/gcc/fold-const.c b/gcc/fold-const.c index 47ed609..6763e80 100644 --- a/gcc/fold-const.c +++ b/gcc/fold-const.c @@ -7770,9 +7770,7 @@ 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 - && (TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST - || TREE_CODE (TREE_OPERAND (arg0, 0)) == NOP_EXPR - || TREE_CODE (TREE_OPERAND (arg0, 1)) == NOP_EXPR)) + && TREE_CODE (TREE_OPERAND (arg0, 0)) == NOP_EXPR) { tree arg00 = TREE_OPERAND (arg0, 0); tree arg01 = TREE_OPERAND (arg0, 1); -- 1.9.1