This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A problem about loop store motion
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Jiangning Liu <jiangning dot liu at arm dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 21 Feb 2012 11:18:32 +0100
- Subject: Re: A problem about loop store motion
- Authentication-results: mr.google.com; spf=pass (google.com: domain of richard.guenther@gmail.com designates 10.50.15.231 as permitted sender) smtp.mail=richard.guenther@gmail.com; dkim=pass header.i=richard.guenther@gmail.com
- References: <4f42088a.ca3c440a.171b.35f7SMTPIN_ADDED@mx.google.com> <CAFiYyc3+DpkPoT2U2H9nZsfiSJ5T5voumSbi-vGW9QySS2QmMA@mail.gmail.com> <4f435bb4.5ae9d80a.5535.5eb1SMTPIN_ADDED@mx.google.com> <CAFiYyc2=XrjxB89LJ1758yEt==DVRdv5zhSPYRXSpT7xYrLYmw@mail.gmail.com> <4f436ab0.c46bb40a.79e8.43cbSMTPIN_ADDED@mx.google.com>
On Tue, Feb 21, 2012 at 10:57 AM, Jiangning Liu <jiangning.liu@arm.com> wrote:
>
>
>> -----Original Message-----
>> From: Richard Guenther [mailto:richard.guenther@gmail.com]
>> Sent: Tuesday, February 21, 2012 5:40 PM
>> To: Jiangning Liu
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: A problem about loop store motion
>>
>> On Tue, Feb 21, 2012 at 9:54 AM, Jiangning Liu <jiangning.liu@arm.com>
>> wrote:
>> >> The MEM form is more "canonical", so the loop SM machinery to detect
>> >> equality should be adjusted accordingly. ?Alternatively you can
>> teach
>> >> PRE insertion to strip off the MEM if possible (though
>> >> fold_stmt_inplace should
>> >> arelady do this if possible).
>> >
>> > Richard,
>> >
>> > Thank you! You are right. I noticed on latest trunk the problem in
>> PRE was
>> > already fixed by invoking fold_stmt_inplace.
>> >
>> > Unfortunately for this small case, the latest trunk code still can't
>> do SM
>> > for variable pos, because refs_may_alias_p(*D.4074_10, pos) is true,
>> that
>> > is, pos has alias with l[pos].
>> >
>> > I think alias analysis should be able to know they don't have alias
>> with
>> > each other, unless there is an assignment statement like "l=&pos;".
>> >
>> > Can alias analysis fix the problem?
>>
>> The problem is that 'pos' is marked TREE_ADDRESSABLE, so we think
>> its address got taken. ?'l' points to any global possibly address-taken
>> variable. ?It get's the TREE_ADDRESSABLE flag via PRE insertion which
>> re-gimplifies the tree it creates which marks the variable as
>> addressable.
>>
>> I'll have a look.
>
> Terrific! :-) Could you please let me know when you have a patch to fix
> this, because I want to double check the big case, and there might be other
> hidden problems?
PR52324, I am testing the following patch (in reality the gimplifier should not
mark things addressable unless it itself makes them so, but frontends are
broken, so we do that ... ugh).
Index: gcc/gimplify.c
===================================================================
--- gcc/gimplify.c (revision 184428)
+++ gcc/gimplify.c (working copy)
@@ -7061,15 +7061,20 @@ gimplify_expr (tree *expr_p, gimple_seq
ret = GS_OK;
break;
}
- ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p, post_p,
- is_gimple_mem_ref_addr, fb_rvalue);
- if (ret == GS_ERROR)
- break;
+ /* Avoid re-gimplifying the address operand if it is already
+ in suitable form. */
+ if (!is_gimple_mem_ref_addr (TREE_OPERAND (*expr_p, 0)))
+ {
+ ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p, post_p,
+ is_gimple_mem_ref_addr, fb_rvalue);
+ if (ret == GS_ERROR)
+ break;
+ }
recalculate_side_effects (*expr_p);
ret = GS_ALL_DONE;
break;
- /* Constants need not be gimplified. */
+ /* Constants need not be gimplified. */
case INTEGER_CST:
case REAL_CST:
case FIXED_CST: