This is the mail archive of the
mailing list for the GCC project.
RE: A problem about loop store motion
> -----Original Message-----
> From: Richard Guenther [mailto:firstname.lastname@example.org]
> Sent: Tuesday, February 21, 2012 5:40 PM
> To: Jiangning Liu
> Cc: email@example.com
> Subject: Re: A problem about loop store motion
> On Tue, Feb 21, 2012 at 9:54 AM, Jiangning Liu <firstname.lastname@example.org>
> >> The MEM form is more "canonical", so the loop SM machinery to detect
> >> equality should be adjusted accordingly. ?Alternatively you can
> >> 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,
> > is, pos has alias with l[pos].
> > I think alias analysis should be able to know they don't have alias
> > 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
> 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
> > Thanks,
> > -Jiangning
> >> Richard.