https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #13 from Hongtao.liu ---
(In reply to rguent...@suse.de from comment #12)
> On Wed, 15 Feb 2023, crazylht at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
> >
> > --- Comment #11 from Hongtao.liu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #12 from rguenther at suse dot de ---
On Wed, 15 Feb 2023, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
>
> --- Comment #11 from Hongtao.liu ---
>
> >
> > There's no other way to do N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #11 from Hongtao.liu ---
>
> There's no other way to do N bit to two N/2 bit hi/lo (un)packing
> (there's a 2x N/2 bit -> N bit operation, for whatever reason).
> There's also no way to transform the d rgroup mask into the
> f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #10 from Hongtao.liu ---
>
> There's no other way to do N bit to two N/2 bit hi/lo (un)packing
> (there's a 2x N/2 bit -> N bit operation, for whatever reason).
> There's also no way to transform the d rgroup mask into the
> f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #9 from Richard Biener ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> (In reply to rguent...@suse.de from comment #7)
> > more like precision but x86 uses QImode for two-element, four-element
> > and eight-element masks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #7)
> more like precision but x86 uses QImode for two-element, four-element
> and eight-element masks (rather than two partial integer modes with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #7 from rguenther at suse dot de ---
On Mon, 10 Oct 2022, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
>
> --- Comment #6 from rsandifo at gcc dot gnu.org
> ---
> The PR means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #6 from rsandifo at gcc dot gnu.org
---
I don't think we should key this off whether the masks are integers
or vectors. In principle there's no reason why a vector-based
couldn't work the AVX512 way, or an integer approach the SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #5 from Richard Biener ---
(In reply to Andrew Stubbs from comment #4)
> I don't understand rgroups, but I can say that GCN masks are very simply
> one-bit-one-lane. There are always 64-lanes, regardless of the type, so
> V64QI mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #4 from Andrew Stubbs ---
I don't understand rgroups, but I can say that GCN masks are very simply
one-bit-one-lane. There are always 64-lanes, regardless of the type, so V64QI
mode has fewer bytes and bits than V64DImode (when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
Richard Biener changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
--- Comment #2 from rsandifo at gcc dot gnu.org
---
See the comment above rgroup_controls in tree-vectorizer.h for the
current assumptions around loop predication. If AVX512 wants something
different then some extensions will be needed :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
CC|
14 matches
Mail list logo
