This is the mail archive of the
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 10:39:45 +0100
- Subject: Re: A problem about loop store motion
- Authentication-results: mr.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates 10.42.19.5 as permitted sender) email@example.com; dkim=pass firstname.lastname@example.org
- References: <4f42088a.ca3c440a.171b.35f7SMTPIN_ADDED@mx.google.com> <CAFiYyc3+DpkPoT2U2H9nZsfiSJ5T5voumSbi-vGW9QySS2QmMA@mail.gmail.com> <4f435bb4.5ae9d80a.5535.5eb1SMTPIN_ADDED@mx.google.com>
On Tue, Feb 21, 2012 at 9:54 AM, Jiangning Liu <email@example.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).
> 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.