On Thu, Aug 27, 2020 at 08:43:40AM -0700, Carl Love wrote:
> 2020-08-26 Carl Love
> * config/rs6000/rs6000-builtin.def: (BU_P10V_VSX_1) New builtin macro
> expansion.
> (XVCVBF16SPN, XVCVSPBF16): Replace macro expansion BU_VSX_1 with
> BU_P10V_VSX_1.
> * config/rs6000/rs6000-
GCC maintainers:
The following patch has been updated based on the comments from Will
and Segher.
The patch is a subset of the mainline commit:
commit
07d456bb80a16405723c98c2ab74ccc2a5a23898
Author: Carl Love
Hi!
(All that Will says included by reference ;-) )
On Mon, Aug 24, 2020 at 02:39:41PM -0700, Carl Love wrote:
> I attempted to do the backport however the patch doesn't even come
> close to applying. The names XVCVBF16SPN and XVCVSPBF16 are the only
> two builtin names that exist in GCC 10. Th
On Mon, 2020-08-24 at 14:39 -0700, Carl Love wrote:
> Segher:
>
> On Wed, 2020-08-19 at 15:16 -0500, Segher Boessenkool wrote:
> > On Wed, Aug 19, 2020 at 02:19:12PM -0500, Peter Bergner wrote:
> > > On 8/14/20 7:42 PM, Segher Boessenkool wrote:
> > > > I think your current code is fine; I hadn't
Segher:
On Wed, 2020-08-19 at 15:16 -0500, Segher Boessenkool wrote:
> On Wed, Aug 19, 2020 at 02:19:12PM -0500, Peter Bergner wrote:
> > On 8/14/20 7:42 PM, Segher Boessenkool wrote:
> > > I think your current code is fine; I hadn't considered Bill's
> > > upcoming
> > > rewrite. It is more impo
On Wed, 2020-08-19 at 15:16 -0500, Segher Boessenkool wrote:
> On Wed, Aug 19, 2020 at 02:19:12PM -0500, Peter Bergner wrote:
> > On 8/14/20 7:42 PM, Segher Boessenkool wrote:
> > > I think your current code is fine; I hadn't considered Bill's
> > > upcoming
> > > rewrite. It is more important to
On Wed, Aug 19, 2020 at 02:19:12PM -0500, Peter Bergner wrote:
> On 8/14/20 7:42 PM, Segher Boessenkool wrote:
> > I think your current code is fine; I hadn't considered Bill's upcoming
> > rewrite. It is more important to make that go smoother than to fix some
> > aesthetics right now.
> >
> > P
On 8/14/20 7:42 PM, Segher Boessenkool wrote:
> I think your current code is fine; I hadn't considered Bill's upcoming
> rewrite. It is more important to make that go smoother than to fix some
> aesthetics right now.
>
> Please check if the names for the builtins match the (future)
> documentatio
Bill:
On Mon, 2020-08-17 at 13:09 -0500, Bill Schmidt wrote:
> >
> > There are three prototypes __builtin_cfuged, __builtin_pdepd,
> > __builtin_pextd defined in the document.
> >
> > The corresponding builtin definitions in GCC are:
> >
> > __builtin_altivec_cfuged, __builtin_altivec_pdep
On 8/17/20 12:13 PM, Carl Love wrote:
Segher, Bill, Peter:
On Fri, 2020-08-14 at 19:42 -0500, Segher Boessenkool wrote:
Do the names agree with the (future) documentation now?
Did not double check on the documentation.
Someone should...
Looking at the box document "Proposed function Prototyp
Segher, Bill, Peter:
On Fri, 2020-08-14 at 19:42 -0500, Segher Boessenkool wrote:
> > > Do the names agree with the (future) documentation now?
> >
> > Did not double check on the documentation.
>
> Someone should...
Looking at the box document "Proposed function Prototypes for P10".
There are
Hi!
On Fri, Aug 14, 2020 at 03:32:47PM -0700, Carl Love wrote:
> On Fri, 2020-08-14 at 16:33 -0500, Segher Boessenkool wrote:
> > So _vsx if it is for all VSRs, but _altivec for just the VRs?
>
> Yes, I worked off the rule that Altivec registers are designated with
> 5-bits and VSR registers are
On Fri, 2020-08-14 at 16:33 -0500, Segher Boessenkool wrote:
> Hi Carl,
>
> On Thu, Aug 13, 2020 at 09:12:48AM -0700, Carl Love wrote:
> > The macro expansion for the bfloat convert intrinsics XVCVBF16SP
> > and
> > XVCVSPBF16 need to be restricted to P10.
> > The following patch creates new macro
Hi Carl,
On Thu, Aug 13, 2020 at 09:12:48AM -0700, Carl Love wrote:
> The macro expansion for the bfloat convert intrinsics XVCVBF16SP and
> XVCVSPBF16 need to be restricted to P10.
> The following patch creates new macro expansions BU_P10V_VSX_# and
> BU_P10V_AV_# for the VSX and Altivec instru
On 8/13/20 3:00 PM, Carl Love wrote:
> On Thu, 2020-08-13 at 14:48 -0500, Bill Schmidt wrote:
>> OK, but that was just meant as an example. We have a fair number of
>> things that changed names, so I was somewhat surprised. It could be
>> that all of these are likewise hidden via the overload m
Bill:
On Thu, 2020-08-13 at 14:48 -0500, Bill Schmidt wrote:
> OK, but that was just meant as an example. We have a fair number of
> things that changed names, so I was somewhat surprised. It could be
> that all of these are likewise hidden via the overload mechanism.
> Just
> checking to b
On 8/13/20 2:24 PM, Carl Love wrote:
Bill:
On Thu, 2020-08-13 at 13:38 -0500, Bill Schmidt wrote:
Hi Carl,
Thanks for cleaning up the consistency issue. The new names and
related
adjustments LGTM.
Are there no affected test cases that need adjusting? That
surprises
me. For example, didn't
Bill:
On Thu, 2020-08-13 at 13:38 -0500, Bill Schmidt wrote:
> Hi Carl,
>
> Thanks for cleaning up the consistency issue. The new names and
> related
> adjustments LGTM.
>
> Are there no affected test cases that need adjusting? That
> surprises
> me. For example, didn't __builtin_altivec_xx
------------
[PATCH] rs6000, restrict bfloat convert intrinsic to Power 10. Fix BU_P10V
macro definitions.
gcc/ChangeLog
2020-08-12 Carl Love
* config/rs6000/rs6000-builtin.def (BU_P10V_0, BU_P10V_1,
BU_P10V_2, BU_P10V_3): Rename BU_P10V_VSX_0, B
ower 8 LE)
powerpc64le-unknown-linux-gnu (Power 9 LE)
with no regressions.
Please let me know if the patch is acceptable for trunk.
Carl Love
---------
[PATCH] rs6000, restrict bfloat convert intrinsic t
20 matches
Mail list logo
