From: Andrew Stubbs <ams@codesourcery.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: <gcc-patches@gcc.gnu.org>
Subject: Re: [OG12 commit] vect: WORKAROUND vectorizer bug
Date: Thu, 27 Oct 2022 14:12:52 +0100 [thread overview]
Message-ID: <811f04f9-be1a-f1f9-bbab-49553b2b40b1@codesourcery.com> (raw)
In-Reply-To: <C7C330FC-AB46-4EDB-B187-E42EFBD6737B@gmail.com>
On 24/10/2022 19:06, Richard Biener wrote:
>
>
>> Am 24.10.2022 um 18:51 schrieb Andrew Stubbs <ams@codesourcery.com>:
>>
>> I've committed this to the OG12 branch to remove some test failures. We probably ought to have something on mainline also, but a proper fix would be better.
>>
>> Without this. the libgomp.oacc-c-c++-common/private-variables.c testcase fails to compile due to an ICE. The OpenACC worker broadcasting code is creating SLP optimizable loads and stores in amdgcn address-space-4. Previously this was "ok" as SLP didn't work with less that 64-lane vectors, but the newly implemented smaller vectors are working as intended and optimizing this.
>>
>> Unfortunately the vectorizer is losing the address-space data from the intermediate types, and it all falls apart during expand when it tries the convert a 32-bit address into a 64-bit address and that's not something that works. At first sight it looks like we could possibly make that work with POINTERS_EXTEND_UNSIGNED, but that only changes the error message. Fundamentally we need to make sure that various instances of "vectype" have the correct address space, but my attempts to do so showed that that's a larger task than I have time for right now.
>
> Istr there were issues like this in the past that I fixed, so any testcase that exposes this with just a gcn cc1 would be nice to have.
I've been unable to reproduce this issue on the mainline compiler. The
SLP vectorizer says the accesses are not consecutive, although I don't
know why they would be different.
A simple testcase works fine on OG12 as well. It's something weird to do
with the OpenACC worker broadcasting code that I can't reproduce manually.
Thank you for the offer. I'll let you know if I get a testcase.
Andrew
prev parent reply other threads:[~2022-10-27 13:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 16:50 Andrew Stubbs
2022-10-24 18:06 ` Richard Biener
2022-10-27 13:12 ` Andrew Stubbs [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=811f04f9-be1a-f1f9-bbab-49553b2b40b1@codesourcery.com \
--to=ams@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).