[ 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?
Thanks,
- Tom
Allow more pointer-plus folding
2015-10-30 Tom de Vries <t...@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
