* 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; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ messages in thread
end of thread, other threads:[~2015-10-31 9:44 UTC | newest]
Thread overview: 5+ 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
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).