This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: PR middle-end/43671: [4.4/4.5/4.6 Regression] -fsched2-use-superblocks -m32 produces wrong code with vectorization
On Tue, May 4, 2010 at 6:07 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, May 04, 2010 at 06:36:40AM -0700, H.J. Lu wrote:
>> I am testing this on Linux/x86-64. ?OK to install on trunk/4.4/4.5
>> if there are no regressions?
>
> Two comments:
> 1) I guess something similar should be done also in memrefs_conflict_p
> ? - there it currently avoids doing get_addr only if either the VALUE
> ? is the same on both sides, or if one side has a VALUE and another
> ? a REG that has that VALUE currently. ?Perhaps also not doing
> ? get_addr if the other side is an expression involving that VALUE
> ? would be helpful.
I think memrefs_conflict_p only disambiguates must-aliases (with
same bases), so it should be safe. But maybe I misremember.
> 2) while I like your change, I don't think it is a real fix here.
> ? It will avoid doing get_addr in the case the same VALUE is somewhere
> ? on both sides, but what if one side has a VALUE on which doing get_addr
> ? will cross from the sp related to hfp related VALUE (i.e.
> ? find_base_term on that VALUE will be (address sp), while find_base_term
> ? on get_addr (VALUE) will be (address bp)), while on the other side there
> ? is another VALUE, on which get_addr will bring return the VALUE on the
> ? first side. ?Then it will still do 2 get_addr calls and find_base_term
> ? will be different, even when they actually are not. ?I don't have a
> ? testcase for this, but perhaps instrumenting the functions to look for
> ? this case could reveal it.
I'd need to think about this ... the change from HJ made sense to
me and I couldn't think of a case we miss.
Richard.
> ? ? ? ?Jakub
>