This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Auto-vectorizer and (mis-)alignment support assumptions
- From: Frederic Riss <frederic dot riss at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 12 Sep 2013 17:39:11 +0200
- Subject: Re: Auto-vectorizer and (mis-)alignment support assumptions
- Authentication-results: sourceware.org; auth=none
- References: <CAKk_3s_aZUj9=EVoC1fjR2F98Wxm-3R62BsEuYD14ODWZYVmFA at mail dot gmail dot com> <CAFiYyc0_6FahQ3CPnRVnEKJN0FdN0W0v9xAjM_R7zLfjZtDvCA at mail dot gmail dot com> <CAKk_3s8uBNZ6LmmJ76KCCnDHQxSMP4Xe6UfbcU140D=TrOmKGQ at mail dot gmail dot com> <CAFiYyc0aDMW8H=1msRZG=wc7Jg0LxErjFpuKisFBagGFniuVeA at mail dot gmail dot com>
On 12 September 2013 12:47, Richard Biener <richard.guenther@gmail.com> wrote:
> Look at the -fdump-tree-vect-details, it should print what it does during
> alignment analysis. Then debug the code ...
OK, I think I got to the bottom of this. It's not the vectorizer fault
after all. Jakub was right to point out that there is checking code
inserted (except that it was for versioning, not peeling). I didn't
investigate at first this because I saw the faulty access actually
happening (and I found it very suspicious that we generate code that
couldn't be correct). The issue is that I am using super-block
scheduling in sched2 and that my sched_reorder hook prioritized the
load operation over the conditional branch that did the alignment
check.
I'm now leaning toward a scheduler bug (or my customization thereof).
I expect superblock scheduling to hoist instructions out of their
original basic-block, but it seems very dangerous to move memory
accesses this way (without speculation). Is it my hook's job to ensure
this reordering doesn't happen? I'd think the memory access shouldn't
be in the ready list in the first place.
Fred