Don't handle CAST_RESTRICT (PR tree-optimization/49279)

[ 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

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
>
>