Re: [PATCH] rs6000: __builtin_darn[_raw] should be in [power9-64] (PR103624)

Hi! On 12/13/21 10:54 AM, Segher Boessenkool wrote: > On Mon, Dec 13, 2021 at 11:30:28AM -0500, David Edelsohn wrote: >> On Mon, Dec 13, 2021 at 10:48 AM Bill Schmidt wrote: >>> Hi! >>> >>> PR103624 observes that we get segfaults for the 64-bit darn builtin

Re: [PATCH] rs6000: Some builtins require IBM-128 long double format (PR103623)

Hi! On 12/13/21 2:15 PM, Martin Sebor wrote: > On 12/13/21 8:55 AM, Bill Schmidt via Gcc-patches wrote: >> Hi! >> >> PR103623 shows that we ICE if __builtin_pack_longdouble or >> __builtin_unpack_longdouble >> is used when long double is not defined to be the I

Re: [PATCH] rs6000: __builtin_darn[_raw] should be in [power9-64] (PR103624)

Hi! On 12/13/21 6:22 PM, Segher Boessenkool wrote: > On Mon, Dec 13, 2021 at 02:37:43PM -0600, Bill Schmidt wrote: >> On 12/13/21 10:54 AM, Segher Boessenkool wrote: >>> On Mon, Dec 13, 2021 at 11:30:28AM -0500, David Edelsohn wrote: >>>> On Mon, Dec 13, 2021 at 10:4

Re: [PATCH] rs6000: __builtin_darn[_raw] should be in [power9-64] (PR103624)

On 12/14/21 7:32 AM, Bill Schmidt wrote: > Hi! > > On 12/13/21 6:22 PM, Segher Boessenkool wrote: >> >> These builtins should just return a "long", just like __builtin_ppc_mftb >> does. All three of them. > Well, that seems wrong for __builtin_darn_32, wh

Re: [PATCH v2 0/6] Remove "old" built-in function infrastructure

Hi!  I'd like to ping patches 2 through 6 of this series.  Much obliged! Thanks, Bill On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote: > Hi! > > Now that the new built-in function support is all upstream and enabled, it > seems safe and prudent to remove the old code t

Re: [PATCH v2 3/6] rs6000: Rename rs6000-builtin-new.def to rs6000-builtins.def

Ping.  Thanks! Bill On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote: > Hi! > > This patch just renames a file and updates the build machinery accordingly. > > Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this > okay for trunk? > > Thank

Re: [PATCH v2 4/6] rs6000: Remove rs6000-builtin.def and associated data and functions

Ping.  Thanks! Bill On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote: > Hi! > > The old rs6000-builtin.def file is no longer needed. Remove it and the code > that depends on it. > > Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this > okay

Re: [PATCH v2 /6] rs6000: Rename functions with "new" in their names

Ping.  Thanks! Bill On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote: > Hi! > > While we had two sets of built-in functionality at the same time, I put "new" > in the names of quite a few functions. Time to undo that. > > Bootstrapped and tested on p

Re: [PATCH v2 6/6] rs6000: Rename arrays to remove temporary _x suffix

Ping.  Thanks! Bill On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote: > Hi! > > While we had two sets of built-in infrastructure at once, I added _x as a > suffix to two arrays to disambiguate the old and new versions. Time to fix > that also. > > Bootstrapped and

Re: [PATCH] rs6000: __builtin_darn[_raw] should be in [power9-64] (PR103624)

On 12/14/21 8:23 PM, Segher Boessenkool wrote: > On Tue, Dec 14, 2021 at 07:32:30AM -0600, Bill Schmidt wrote: >> On 12/13/21 6:22 PM, Segher Boessenkool wrote: >>> On Mon, Dec 13, 2021 at 02:37:43PM -0600, Bill Schmidt wrote: >>>> On 12/13/21 10:54 AM, Segher B

[PATCH] rs6000: Refactor altivec_build_resolved_builtin

egressions. Is this okay for trunk? Thanks! Bill 2021-12-09 Bill Schmidt gcc/ * config/rs6000/rs6000-c.c (resolution): New enum. (resolve_VEC_MUL): New function. (resolve_VEC_CMPNE): Likewise. (resolve_VEC_ADDE_SUBE): Likewise. (resolve_VEC_ADDEC_SUBEC)

Re: [PATCH] rs6000: __builtin_darn[_raw] should be in [power9-64] (PR103624)

On 12/15/21 12:41 PM, Segher Boessenkool wrote: > On Wed, Dec 15, 2021 at 08:00:02AM -0600, Bill Schmidt wrote: >>> No, all builtins should work in either mode, and always return long. >>> If the patterns are broken, the *patterns* should be fixed :-) >> OK, thanks

Re: [PATCH] rs6000: Refactor altivec_build_resolved_builtin

Hi! On 12/15/21 12:16 PM, Segher Boessenkool wrote: >> + /* Note: vec_nand also works but opt changes vec_nand's >> + to vec_nor's anyway. */ > Maybe there should be a vec_not? There is one at the RTL level (called > one_cmpl2). As I recall, we have an issue open for this already.

Re: [pushed] Darwin, ppc: Additional change for r12-5974.

Iain, thanks very much for fixing this, and I'm very sorry for the oversight! Bill On 12/17/21 3:46 AM, Iain Sandoe via Gcc-patches wrote: > This adds a missed change from r12-5974-g926d64906af. > The builin_decls array has been renamed to drop the trailing > _x that was used during the main chan

[COMMITTED] rs6000: Fix fake vec_promote overload

Hi! rs6000-overload.def defines one instance of vec_promote so that it can be registered with the front end. Actual expansion of the vec_promote overload is done with special-case code in rs6000-c.c. During another cleanup, I observed that the fake instance has the wrong number of arguments. Fi

Re: [PATCH 1/2] rs6000: Redo darn (PR103624)

Hi! On 12/17/21 11:36 AM, Segher Boessenkool wrote: > The builtins now all return "long". The patterns have :GPR as the > output mode, so they can be 32-bit as well (the instruction makes sense > in 32 bit just fine). The builtins expand to the DImode version > normally, but to the SImode if {32

Re: [PATCH 2/2] rs6000: Update darn testcases

Hi! On 12/17/21 11:36 AM, Segher Boessenkool wrote: > Make the darn testcases work (and be tested) in 32-bit mode as well. > They used to ICE, but they no longer do. > > > 2021-12-17 Segher Boessenkool > > gcc/testsuite/ > PR target/103624 > * gcc.target/powerpc/darn-0.c: Remove targ

Re: [PATCH] rs6000: Skip overload instances with uninitialized fntype (PR103622)

Hi!  I'd like to ping this patch, now that I'm back from break. Thanks! Bill On 12/13/21 10:15 AM, Bill Schmidt wrote: > Hi! > > For some data types like IEEE-128, we determine whether the type is available > at built-in function initialization time. If it's not,

[PATCH] rs6000: More factoring of overload processing

d and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Thanks! Bill 2022-01-06 Bill Schmidt gcc/ * config/rs6000/rs6000-c.c (resolve_vec_mul): Accept args and types parameters instead of arglist and nargs. Simplify accordingly. Remove unnec

[PATCH] rs6000: Don't #ifdef "short" built-in names

able using __attribute__((target)), so I failed in this respect. This patch corrects the problem by removing the apply. For example, #ifdef __PPU__ is still appropriate. Bootstrapped and tested on powerpc64le-linux-gnu. Is this okay for trunk? Thanks! Bill 2022-01-06 Bill Schmidt gcc/

Re: [PATCH] PR 102935, Fix pr101384-1.c code generation test.

Hi Mike, This looks fine to me.  Maintainers? Thanks, Bill On 1/7/22 6:33 PM, Michael Meissner wrote: > Fix pr101384-1.c code generation test. > > Add support for the compiler using XXSPLTIB reg,255 to load all 1's into a > register on power9 and above instead of using VSPLTI{B,H,W} reg,-1. > >

Re: [vect] PR103971, PR103977: Fix epilogue mode selection for autodetect only

I think we need a fix or a revert for this today, please.  Bootstrap has been broken for a couple of days during the last week of stage 3, which is really problematic. Thanks, Bill On 1/12/22 6:57 AM, Richard Biener via Gcc-patches wrote: > On Wed, 12 Jan 2022, Andre Vieira (lists) wrote: > >>

[PATCH] rs6000: Convert built-in constraints to form

7;ve added a note in rs6000-builtins.def that this form is deprecated in favor of . I think it's harmless to leave it in, in case a desire for the distinction comes up in the future. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk?

<    11   12   13   14   15   16