* Re: [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279)
@ 2015-10-29 11:00 Tom de Vries
2015-10-29 12:05 ` Richard Biener
0 siblings, 1 reply; 7+ messages in thread
From: Tom de Vries @ 2015-10-29 11:00 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]
[ 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?
Thanks,
- Tom
[-- Attachment #2: 0016-Allow-CAST_RESTRICT-folding.patch --]
[-- Type: text/x-patch, Size: 842 bytes --]
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279)
2015-10-29 11:00 [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279) Tom de Vries
@ 2015-10-29 12:05 ` Richard Biener
2015-10-30 8:59 ` [PATCH] Allow more pointer-plus folding Tom de Vries
0 siblings, 1 reply; 7+ messages in thread
From: Richard Biener @ 2015-10-29 12:05 UTC (permalink / raw)
To: Tom de Vries; +Cc: Jakub Jelinek, gcc-patches
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
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] Allow more pointer-plus folding
2015-10-29 12:05 ` Richard Biener
@ 2015-10-30 8:59 ` Tom de Vries
2015-10-30 9:29 ` Richard Biener
0 siblings, 1 reply; 7+ messages in thread
From: Tom de Vries @ 2015-10-30 8:59 UTC (permalink / raw)
To: Richard Biener; +Cc: Jakub Jelinek, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]
[ 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?
Thanks,
- Tom
[-- Attachment #2: 0001-Allow-more-pointer-plus-folding.patch --]
[-- Type: text/x-patch, Size: 931 bytes --]
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Allow more pointer-plus folding
2015-10-30 8:59 ` [PATCH] Allow more pointer-plus folding Tom de Vries
@ 2015-10-30 9:29 ` Richard Biener
2015-10-31 10:24 ` [committed] Tune " Tom de Vries
0 siblings, 1 reply; 7+ messages in thread
From: Richard Biener @ 2015-10-30 9:29 UTC (permalink / raw)
To: Tom de Vries; +Cc: Jakub Jelinek, gcc-patches
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [committed] Tune pointer-plus folding
2015-10-30 9:29 ` Richard Biener
@ 2015-10-31 10:24 ` Tom de Vries
0 siblings, 0 replies; 7+ messages in thread
From: Tom de Vries @ 2015-10-31 10:24 UTC (permalink / raw)
To: Richard Biener; +Cc: Jakub Jelinek, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
[ was: Re: [PATCH] Allow more pointer-plus folding ]
On 30/10/15 10:24, Richard Biener wrote:
>>> 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.
Committed to trunk as attached, with:
- fold-const.c comment updated, and
- two test-cases updated (where we do less folding than before).
And I've changed the title of the commit since although we do allow more
folding in some cases, we allow less folding in other cases.
Thanks,
- Tom
[-- Attachment #2: 0001-Tune-pointer-plus-folding.patch --]
[-- Type: text/x-patch, Size: 3526 bytes --]
Tune pointer-plus folding
2015-10-30 Tom de Vries <tom@codesourcery.com>
* fold-const.c (fold_unary_loc): Tune POINTER_PLUS_EXPR folding.
* gfortran.dg/assumed_type_2.f90: Update test.
* gfortran.dg/no_arg_check_2.f90: Same.
---
gcc/fold-const.c | 10 ++++------
gcc/testsuite/gfortran.dg/assumed_type_2.f90 | 2 +-
gcc/testsuite/gfortran.dg/no_arg_check_2.f90 | 2 +-
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index b9168f3..197ccfd 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -7755,14 +7755,12 @@ fold_unary_loc (location_t loc, enum tree_code code, tree type, tree op0)
}
}
- /* Convert (T1)(X p+ Y) into ((T1)X p+ Y), for pointer type,
- when one of the new casts will fold away. Conservatively we assume
- that this happens when X or Y is NOP_EXPR or Y is INTEGER_CST. */
+ /* Convert (T1)(X p+ Y) into ((T1)X p+ Y), for pointer type, when the new
+ cast (T1)X will fold away. We assume that this happens when X itself
+ is a cast. */
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))
+ && CONVERT_EXPR_P (TREE_OPERAND (arg0, 0)))
{
tree arg00 = TREE_OPERAND (arg0, 0);
tree arg01 = TREE_OPERAND (arg0, 1);
diff --git a/gcc/testsuite/gfortran.dg/assumed_type_2.f90 b/gcc/testsuite/gfortran.dg/assumed_type_2.f90
index ec51b8b..f1a2074 100644
--- a/gcc/testsuite/gfortran.dg/assumed_type_2.f90
+++ b/gcc/testsuite/gfortran.dg/assumed_type_2.f90
@@ -155,7 +155,7 @@ end
! { dg-final { scan-tree-dump-times "sub_scalar .&\\(.\\(struct t2.0:. . restrict\\) array_t2_alloc.data" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_scalar .&\\(.\\(struct t3.0:. .\\) array_t3_ptr.data" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_scalar .\\(struct t1 .\\) array_class_t1_alloc._data.data" 1 "original" } }
-! { dg-final { scan-tree-dump-times "sub_scalar .\\(struct t1 .\\) array_class_t1_ptr._data.dat" 1 "original" } }a
+! { dg-final { scan-tree-dump-times "sub_scalar .\\(struct t1 .\\) \\(array_class_t1_ptr._data.dat" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(D" 3 "original" } }
! { dg-final { scan-tree-dump-times " = _gfortran_internal_pack \\(&parm" 1 "original" } }
diff --git a/gcc/testsuite/gfortran.dg/no_arg_check_2.f90 b/gcc/testsuite/gfortran.dg/no_arg_check_2.f90
index 3645ded..b3fb468 100644
--- a/gcc/testsuite/gfortran.dg/no_arg_check_2.f90
+++ b/gcc/testsuite/gfortran.dg/no_arg_check_2.f90
@@ -137,7 +137,7 @@ end
! { dg-final { scan-tree-dump-times "sub_scalar .&\\(.\\(struct t2.0:. . restrict\\) array_t2_alloc.data" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_scalar .&\\(.\\(struct t3.0:. .\\) array_t3_ptr.data" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_scalar .\\(struct t1 .\\) array_class_t1_alloc._data.data" 1 "original" } }
-! { dg-final { scan-tree-dump-times "sub_scalar .\\(struct t1 .\\) array_class_t1_ptr._data.dat" 1 "original" } }a
+! { dg-final { scan-tree-dump-times "sub_scalar .\\(struct t1 .\\) \\(array_class_t1_ptr._data.dat" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(D" 3 "original" } }
! { dg-final { scan-tree-dump-times " = _gfortran_internal_pack \\(&parm" 1 "original" } }
--
1.9.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279)
2011-10-06 14:45 [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279) Jakub Jelinek
@ 2011-10-06 15:02 ` Richard Guenther
0 siblings, 0 replies; 7+ messages in thread
From: Richard Guenther @ 2011-10-06 15:02 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Thu, 6 Oct 2011, Jakub Jelinek wrote:
> Hi!
>
> 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?
Ok for trunk. Ok for 4.6 with the tree-ssa.c change omitted -
and the stmt folding patch applied.
Thanks,
Richard.
> 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.
>
> --- gcc/tree-ssa-structalias.c.jj 2011-10-04 10:18:29.000000000 +0200
> +++ gcc/tree-ssa-structalias.c 2011-10-05 12:43:42.000000000 +0200
> @@ -4494,15 +4494,6 @@ find_func_aliases (gimple origt)
> && (!in_ipa_mode
> || DECL_EXTERNAL (lhsop) || TREE_PUBLIC (lhsop)))
> make_escape_constraint (rhsop);
> - /* If this is a conversion of a non-restrict pointer to a
> - restrict pointer track it with a new heapvar. */
> - else if (gimple_assign_cast_p (t)
> - && POINTER_TYPE_P (TREE_TYPE (rhsop))
> - && POINTER_TYPE_P (TREE_TYPE (lhsop))
> - && !TYPE_RESTRICT (TREE_TYPE (rhsop))
> - && TYPE_RESTRICT (TREE_TYPE (lhsop)))
> - make_constraint_from_restrict (get_vi_for_tree (lhsop),
> - "CAST_RESTRICT");
> }
> /* Handle escapes through return. */
> else if (gimple_code (t) == GIMPLE_RETURN
> --- gcc/tree-ssa-forwprop.c.jj 2011-10-04 14:36:00.000000000 +0200
> +++ gcc/tree-ssa-forwprop.c 2011-10-05 12:46:32.000000000 +0200
> @@ -804,11 +804,6 @@ forward_propagate_addr_expr_1 (tree name
> && ((rhs_code == SSA_NAME && rhs == name)
> || CONVERT_EXPR_CODE_P (rhs_code)))
> {
> - /* Don't propagate restrict pointer's RHS. */
> - if (TYPE_RESTRICT (TREE_TYPE (lhs))
> - && !TYPE_RESTRICT (TREE_TYPE (name))
> - && !is_gimple_min_invariant (def_rhs))
> - return false;
> /* Only recurse if we don't deal with a single use or we cannot
> do the propagation to the current statement. In particular
> we can end up with a conversion needed for a non-invariant
> --- gcc/tree-ssa.c.jj 2011-09-15 12:18:54.000000000 +0200
> +++ gcc/tree-ssa.c 2011-10-05 12:44:52.000000000 +0200
> @@ -1270,12 +1270,6 @@ useless_type_conversion_p (tree outer_ty
> != TYPE_ADDR_SPACE (TREE_TYPE (inner_type)))
> return false;
>
> - /* Do not lose casts to restrict qualified pointers. */
> - if ((TYPE_RESTRICT (outer_type)
> - != TYPE_RESTRICT (inner_type))
> - && TYPE_RESTRICT (outer_type))
> - return false;
> -
> /* If the outer type is (void *), the conversion is not necessary. */
> if (VOID_TYPE_P (TREE_TYPE (outer_type)))
> return true;
> --- gcc/testsuite/gcc.dg/tree-ssa/restrict-4.c.jj 2011-10-04 14:33:08.000000000 +0200
> +++ gcc/testsuite/gcc.dg/tree-ssa/restrict-4.c 2011-10-05 16:22:33.232433231 +0200
> @@ -22,5 +22,5 @@ bar (int *x, int y)
> return p1[y];
> }
>
> -/* { dg-final { scan-tree-dump-times "return 1;" 2 "optimized" } } */
> +/* { dg-final { scan-tree-dump-times "return 1;" 2 "optimized" { xfail *-*-* } } } */
> /* { dg-final { cleanup-tree-dump "optimized" } } */
> --- gcc/testsuite/gcc.c-torture/execute/pr49279.c.jj 2011-10-05 13:32:43.087670846 +0200
> +++ gcc/testsuite/gcc.c-torture/execute/pr49279.c 2011-10-05 13:32:43.087670846 +0200
> @@ -0,0 +1,35 @@
> +/* PR tree-optimization/49279 */
> +extern void abort (void);
> +
> +struct S { int a; int *__restrict p; };
> +
> +__attribute__((noinline, noclone))
> +struct S *bar (struct S *p)
> +{
> + struct S *r;
> + asm volatile ("" : "=r" (r) : "0" (p) : "memory");
> + return r;
> +}
> +
> +__attribute__((noinline, noclone))
> +int
> +foo (int *p, int *q)
> +{
> + struct S s, *t;
> + s.a = 1;
> + s.p = p;
> + t = bar (&s);
> + t->p = q;
> + s.p[0] = 0;
> + t->p[0] = 1;
> + return s.p[0];
> +}
> +
> +int
> +main ()
> +{
> + int a, b;
> + if (foo (&a, &b) != 1)
> + abort ();
> + return 0;
> +}
>
> Jakub
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279)
@ 2011-10-06 14:45 Jakub Jelinek
2011-10-06 15:02 ` Richard Guenther
0 siblings, 1 reply; 7+ messages in thread
From: Jakub Jelinek @ 2011-10-06 14:45 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc-patches
Hi!
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.
--- gcc/tree-ssa-structalias.c.jj 2011-10-04 10:18:29.000000000 +0200
+++ gcc/tree-ssa-structalias.c 2011-10-05 12:43:42.000000000 +0200
@@ -4494,15 +4494,6 @@ find_func_aliases (gimple origt)
&& (!in_ipa_mode
|| DECL_EXTERNAL (lhsop) || TREE_PUBLIC (lhsop)))
make_escape_constraint (rhsop);
- /* If this is a conversion of a non-restrict pointer to a
- restrict pointer track it with a new heapvar. */
- else if (gimple_assign_cast_p (t)
- && POINTER_TYPE_P (TREE_TYPE (rhsop))
- && POINTER_TYPE_P (TREE_TYPE (lhsop))
- && !TYPE_RESTRICT (TREE_TYPE (rhsop))
- && TYPE_RESTRICT (TREE_TYPE (lhsop)))
- make_constraint_from_restrict (get_vi_for_tree (lhsop),
- "CAST_RESTRICT");
}
/* Handle escapes through return. */
else if (gimple_code (t) == GIMPLE_RETURN
--- gcc/tree-ssa-forwprop.c.jj 2011-10-04 14:36:00.000000000 +0200
+++ gcc/tree-ssa-forwprop.c 2011-10-05 12:46:32.000000000 +0200
@@ -804,11 +804,6 @@ forward_propagate_addr_expr_1 (tree name
&& ((rhs_code == SSA_NAME && rhs == name)
|| CONVERT_EXPR_CODE_P (rhs_code)))
{
- /* Don't propagate restrict pointer's RHS. */
- if (TYPE_RESTRICT (TREE_TYPE (lhs))
- && !TYPE_RESTRICT (TREE_TYPE (name))
- && !is_gimple_min_invariant (def_rhs))
- return false;
/* Only recurse if we don't deal with a single use or we cannot
do the propagation to the current statement. In particular
we can end up with a conversion needed for a non-invariant
--- gcc/tree-ssa.c.jj 2011-09-15 12:18:54.000000000 +0200
+++ gcc/tree-ssa.c 2011-10-05 12:44:52.000000000 +0200
@@ -1270,12 +1270,6 @@ useless_type_conversion_p (tree outer_ty
!= TYPE_ADDR_SPACE (TREE_TYPE (inner_type)))
return false;
- /* Do not lose casts to restrict qualified pointers. */
- if ((TYPE_RESTRICT (outer_type)
- != TYPE_RESTRICT (inner_type))
- && TYPE_RESTRICT (outer_type))
- return false;
-
/* If the outer type is (void *), the conversion is not necessary. */
if (VOID_TYPE_P (TREE_TYPE (outer_type)))
return true;
--- gcc/testsuite/gcc.dg/tree-ssa/restrict-4.c.jj 2011-10-04 14:33:08.000000000 +0200
+++ gcc/testsuite/gcc.dg/tree-ssa/restrict-4.c 2011-10-05 16:22:33.232433231 +0200
@@ -22,5 +22,5 @@ bar (int *x, int y)
return p1[y];
}
-/* { dg-final { scan-tree-dump-times "return 1;" 2 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "return 1;" 2 "optimized" { xfail *-*-* } } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */
--- gcc/testsuite/gcc.c-torture/execute/pr49279.c.jj 2011-10-05 13:32:43.087670846 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr49279.c 2011-10-05 13:32:43.087670846 +0200
@@ -0,0 +1,35 @@
+/* PR tree-optimization/49279 */
+extern void abort (void);
+
+struct S { int a; int *__restrict p; };
+
+__attribute__((noinline, noclone))
+struct S *bar (struct S *p)
+{
+ struct S *r;
+ asm volatile ("" : "=r" (r) : "0" (p) : "memory");
+ return r;
+}
+
+__attribute__((noinline, noclone))
+int
+foo (int *p, int *q)
+{
+ struct S s, *t;
+ s.a = 1;
+ s.p = p;
+ t = bar (&s);
+ t->p = q;
+ s.p[0] = 0;
+ t->p[0] = 1;
+ return s.p[0];
+}
+
+int
+main ()
+{
+ int a, b;
+ if (foo (&a, &b) != 1)
+ abort ();
+ return 0;
+}
Jakub
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-10-31 9:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-29 11:00 [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279) Tom de Vries
2015-10-29 12:05 ` Richard Biener
2015-10-30 8:59 ` [PATCH] Allow more pointer-plus folding Tom de Vries
2015-10-30 9:29 ` Richard Biener
2015-10-31 10:24 ` [committed] Tune " Tom de Vries
-- strict thread matches above, loose matches on Subject: below --
2011-10-06 14:45 [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279) Jakub Jelinek
2011-10-06 15:02 ` Richard Guenther
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).