Re: [PATCH] rs6000: Fix a handful of 32-bit built-in function problems in the new support

Hi Segher, On 11/14/21 9:29 AM, Segher Boessenkool wrote: > Hi! > > On Sun, Nov 14, 2021 at 08:17:41AM -0600, Bill Schmidt wrote: >> On 11/11/21 10:50 AM, Bill Schmidt wrote: >>> On 11/11/21 7:11 AM, Segher Boessenkool wrote: void f(long x) { __builtin_set_texasr(x); } built with

Re: [PATCH] rs6000: Builtins test changes for BFP scalar tests

Hi! On 11/17/21 5:06 PM, Bill Schmidt wrote: > On 11/17/21 3:32 PM, Segher Boessenkool wrote: >> On Wed, Nov 17, 2021 at 02:58:54PM -0600, Bill Schmidt wrote: >>> Hi! This patch is broken out of the previous patch for all the builtins >>> test >>> suite adjustments. Here we have some slight

[PATCH] rs6000: Builtins test changes for byte-in-set-2.c

Hi! This patch is broken out from the previous patch for builtins test suite changes. With the old builtins support, this test case produces: warning: implicit declaration of function '__builtin_byte_in_set'; did you mean '__builtin_byte_in_range'? With the new support, it produces: error:

[PATCH] rs6000: Builtins test changes for compare-bytes tests

Hi! This patch is broken out from the patch with test suite changes for the new builtins support. With the old builtins support, cmpb-2.c produces: warning: implicit declaration of function '__builtin_cmpb; did you mean '__builtin_bcmp'? With the new support, it produces: error:

Re: [PATCH 18/18] rs6000: Add escape-newline support for builtins files

On 11/5/21 6:50 PM, Segher Boessenkool wrote: > Hi! > > On Wed, Sep 01, 2021 at 11:13:54AM -0500, Bill Schmidt wrote: >> +/* Escape-newline support. For readability, we prefer to allow developers >> + to use escape-newline to continue long lines to the next one. We >> + maintain a buffer of

Re: [PATCH 14/18] rs6000: Debug support

On 11/5/21 4:34 PM, Segher Boessenkool wrote: > On Wed, Sep 01, 2021 at 11:13:50AM -0500, Bill Schmidt wrote: >> * config/rs6000/rs6000-call.c (rs6000_debug_type): New function. >> (def_builtin): Change debug formatting for easier parsing and >> include more information. >>

[PATCH] rs6000: Match recent builtins changes in new builtins support

Hi! Over the last month or so, Haochen made a couple of changes to the builtins support that need to be reflected into the new builtin support: 14e355df Disable gimple folding for vector min/max without fast-math 91419baf Optimize vec_xl_sext In both cases these require almost identical

[PATCH] rs6000: Fix a handful of 32-bit built-in function problems in the new support

Hi! Some time ago I realized I hadn't tested the new builtin support against 32-bit big-endian in quite a while. When I did, I found a handful of errors that needed correcting. - One builtin needs to be disabled for 32-bit. - One builtin needs to be restricted to 32-bit only. - One builtin

Re: [PATCH v2] libstdc++: Add support for POWER9 DARN instruction to std::random_device

For posterity:  This was discussed briefly on IRC, and Segher approved with some simplifications and a request to implement a fail/retry check. Thanks, Bill On 11/3/21 10:02 AM, Jonathan Wakely wrote: > On Wed, 3 Nov 2021 at 15:01, Jonathan Wakely wrote: Any feedback from POWER > maintainers

Re: [PATCH v2] libstdc++: Add support for POWER9 DARN instruction to std::random_device

On 11/5/21 7:44 AM, Jonathan Wakely wrote: > On Thu, 4 Nov 2021 at 20:44, Bill Schmidt wrote: For posterity:  This was > discussed briefly on IRC, and Segher approved with some simplifications and a > request to implement a fail/retry check. Here's what I have now. No more > assembler check

Re: [PATCH 11/18] rs6000: Builtin expansion, part 6

Hi Segher, Thank you for all of the reviews!  I appreciate your hard work and thorough study of the patches. I've updated these 6 patches and combined them into 1, pushed today.  There are still a couple of cleanups I haven't done, but I made note in the code where these are needed. Thanks

Re: [PATCH 11/18] rs6000: Builtin expansion, part 6

Sorry for the misunderstanding.  What I meant is the 6 patches entitled "Builtin expansion, part N". I still have 6-7 patches left to look at. Thanks! Bill On 11/7/21 3:05 PM, Segher Boessenkool wrote: > Hi! > > On Sun, Nov 07, 2021 at 09:28:09AM -0600, Bill Schmidt wrote: >> Thank you for all

Re: [PING] rs600 built-in series

Ping... On 10/11/21 5:17 PM, Bill Schmidt wrote: > Hi!  Ping, please. :-) > > Bill > > On 9/29/21 3:38 PM, Bill Schmidt wrote: >> Hi Segher, >> >> Might as well ping this before I go on vacation.  :-)  I think we're up to >> 06/18: >> >>

[PATCH] rs6000: Fix use of wrong enum for built-in function code.

Hi! I discovered this bug while working on patches to remove the old built-ins infrastructure. I missed a spot in converting from the rs6000_builtins enum to the rs6000_gen_builtins enum. This fixes it. The fix is technically not right if new_builtins_are_enabled were to be set to zero, but

Re: [PATCH v2] rs6000: Fix a handful of 32-bit built-in function problems

Hi! I'd like to ping this patch. By the way, the diagnostics are improved [1] since I sent it, so that we now inform the user that the overloaded function is implemented by the instantiated function. Thanks! Bill [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585250.html On

[PATCH, PING] rs6000: Builtins test changes for test_fpscr_[d]rn_builtin_error.c

Hi!  I'd like to ping this patch. Thanks! Bill On 11/18/21 10:36 AM, Bill Schmidt wrote: > Hi! This is the last patch broken out of the previous test suite patch > for the new builtins support. > > One advantage of the new builtins support is uniform error messages for > arguments with

[PATCH, PING] rs6000: Builtins test changes for BFP scalar tests

Hi! I'd like to ping this patch. Segher had objected to the change in diagnostics, but I hope we've solved that now with the better informational message [1]. Thanks! Bill [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585250.html On 11/17/21 2:58 PM, Bill Schmidt wrote: > Hi!

Re: [PATCH] rs6000: Mirror fix for PR102347 into the new builtins support

On 12/1/21 11:21 AM, Segher Boessenkool wrote: > Hi! > > On Wed, Dec 01, 2021 at 09:29:42AM -0600, Bill Schmidt wrote: >> Recently Kewen fixed a problem in the old builtins support where >> rs6000_builtin_decl prematurely indicated that a target builtin is >> unavailable. This also needs to be

[PATCH, PING] rs6000: Builtins test changes for pr80315-*.c, pr88100.c

Hi!  I'd like to ping this patch. Thanks! Bill On 11/18/21 10:15 AM, Bill Schmidt wrote: > Hi! This patch is broken out from the test case patch for the new > builtins support. > > One advantage of the new builtins support is uniform error messages for > arguments with restricted values.

[PATCH, PING] rs6000: Builtins test changes for pragma_misc9.c

Hi!  I'd like to ping this patch. Thanks! Bill On 11/18/21 10:18 AM, Bill Schmidt wrote: > Hi! This patch is broken out from the test suite patch for the new > builtins support. This one is just a minor adjustment for the error > message wording. > > Tested on powerpc64le-linux-gnu and

[PATCH, PING] rs6000: Builtins test changes for compare-bytes tests

Hi!  I'd like to ping this patch. Thanks! Bill On 11/18/21 7:47 AM, Bill Schmidt wrote: > Hi! This patch is broken out from the patch with test suite changes for the > new builtins support. > > With the old builtins support, cmpb-2.c produces: > warning: implicit declaration of function

[PATCH] rs6000: Mirror fix for PR102347 into the new builtins support

Hi! Recently Kewen fixed a problem in the old builtins support where rs6000_builtin_decl prematurely indicated that a target builtin is unavailable. This also needs to be done for the new builtins support, but in this case we have to ensure the error message is still produced from the overload

Re: [PATCH] rs6000: Builtins test changes for test_fpscr_[d]rn_builtin_error.c

Hi! On 12/1/21 5:00 PM, Segher Boessenkool wrote: > On Thu, Nov 18, 2021 at 10:36:52AM -0600, Bill Schmidt wrote: >> Hi! This is the last patch broken out of the previous test suite patch >> for the new builtins support. > Whew :-) > >> One advantage of the new builtins support is uniform error

Re: [PATCH] rs6000: Builtins test changes for pr80315-*.c, pr88100.c

Hi! On 12/1/21 4:29 PM, Segher Boessenkool wrote: > On Thu, Nov 18, 2021 at 10:15:21AM -0600, Bill Schmidt wrote: >> Hi! This patch is broken out from the test case patch for the new >> builtins support. >> >> One advantage of the new builtins support is uniform error messages for >> arguments

Re: [PATCH v2] rs6000: Fix a handful of 32-bit built-in function problems

Hi! On 12/1/21 3:08 PM, Segher Boessenkool wrote: > On Tue, Nov 16, 2021 at 12:56:52PM -0600, Bill Schmidt wrote: >> Hi! I previously posted [1] to correct some problems with the new builtins >> support targeting 32-bit code gen. Based on the discussion, I've made some >> adjustments and would

[PATCH] rs6000: Refactor altivec_build_resolved_builtin

Hi! While replacing the built-in machinery, we agreed to defer some necessary refactoring of the overload processing. This patch cleans it up considerably. I've put in one FIXME for an additional level of cleanup that should be done independently. The various helper functions (resolve_VEC_*)

Re: [PATCH] rs6000: Refactor altivec_build_resolved_builtin

I forgot to point out that this patch is dependent on the pending patches to remove the old builtins code. Thanks, Bill On 12/9/21 12:33 PM, Bill Schmidt via Gcc-patches wrote: > Hi! > > While replacing the built-in machinery, we agreed to defer some necessary > refactoring of

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

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 IBM-128 (double-double) format. To solve this, I introduce a new built-in function attribute "ibmld" that enforces this requirement. Tested the fix on a

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

Hi! PR103624 observes that we get segfaults for the 64-bit darn builtins when compiled on a 32-bit architecture. The old built-in infrastructure requires TARGET_64BIT, and this was missed in the new support. Moving these two builtins from the [power9] stanza to the [power9-64] stanza solves

[PATCH] rs6000: Builtins for doubleword compare should be in [power8-vector] (PR103625)

Hi! PR103625 observes that we ICE when doing vector compares on doublewords. The original built-in function support requires Power8 vector support for these, but this was missed in the new built-in support. Moving these functions to the [power8-vector] stanza solves the problem. Tested the fix

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

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, then we don't provide the function type for function instances that require the data type. PR103622 observes that this can cause us to ICE when running the

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, which maps to an SImode pattern. > > So, I

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 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 to avo

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 tes

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] 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:48 AM Bill Schmidt

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 Boessenkool wrote: > On Mon,

[PATCH] rs6000: Refactor altivec_build_resolved_builtin

Hi! While replacing the built-in machinery, we agreed to defer some necessary refactoring of the overload processing. This patch cleans it up considerably. I've put in one FIXME for an additional level of cleanup that should be done independently. The various helper functions (resolve_VEC_*)

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

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! This is much clearer now. >>

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

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 powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Thanks! Bill 2021-12-02 Bill Schmidt gcc/ *

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 builtins when >>> compiled >>> on a 32-bit

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 10/55] rs6000: Main function with stubs for parsing and output

Hi Segher, On 7/19/21 2:15 PM, Segher Boessenkool wrote: Hi! On Thu, Jun 17, 2021 at 10:18:54AM -0500, Bill Schmidt wrote: * config/rs6000/rs6000-gen-builtins.c (rbtree.h): New #include. (num_bifs): New variable. (num_ovld_stanzas): Likewise. (num_ovlds):

Re: [PATCH 10/55] rs6000: Main function with stubs for parsing and output

On 7/20/21 6:22 PM, Segher Boessenkool wrote: Hi! On Tue, Jul 20, 2021 at 05:19:54PM -0500, Bill Schmidt wrote: See the main function.  All three files are guaranteed to have been opened for writing when this is called, but some of them may have already been closed.  So the fclose calls may

Re: [PATCH 10/55] rs6000: Main function with stubs for parsing and output

On 7/21/21 11:08 AM, Bill Schmidt wrote: On 7/21/21 10:43 AM, Segher Boessenkool wrote: On Tue, Jul 20, 2021 at 08:51:58PM -0500, Bill Schmidt wrote: On 7/20/21 6:22 PM, Segher Boessenkool wrote: On Tue, Jul 20, 2021 at 05:19:54PM -0500, Bill Schmidt wrote: See the main function.  All

Re: [PATCH 10/55] rs6000: Main function with stubs for parsing and output

On 7/21/21 10:43 AM, Segher Boessenkool wrote: On Tue, Jul 20, 2021 at 08:51:58PM -0500, Bill Schmidt wrote: On 7/20/21 6:22 PM, Segher Boessenkool wrote: On Tue, Jul 20, 2021 at 05:19:54PM -0500, Bill Schmidt wrote: See the main function.  All three files are guaranteed to have been opened

[PATCH, committed] rs6000: Add int128 target check to pr101129.c (PR101531)

Hi, PR101531 observes that gcc.target/powerpc/pr191129.c fails on 32-bit targets.  I overlooked that the OP's test case has an __int128 dependency.  This patch fixes the obvious oversight. Committed as obvious.  I plan to backport to 11, 10, and 9 once the 11.2 release is complete. Thanks!

Re: [PATCH v2 4/6] rs6000: Add tests for SSE4.1 "ceil" intrinsics

Hi Paul, Thanks for the cleanup, LGTM!  Recommend maintainers approve. Bill On 7/16/21 8:50 AM, Paul A. Clarke wrote: Add the tests for _mm_ceil_pd, _mm_ceil_ps, _mm_ceil_sd, _mm_ceil_ss. Copy a test for _mm_ceil_pd and _mm_ceil_ps from gcc/testsuite/gcc.target/i386. Define __VSX_SSE2__ to

Re: [PATCH v3 2/2] rs6000: Add test for _mm_minpos_epu16

Hi Paul, Thanks for the cleanups, LGTM!  Recommend maintainers approve. Bill On 7/15/21 6:29 PM, Paul A. Clarke wrote: Copy the test for _mm_minpos_epu16 from gcc/testsuite/gcc.target/i386/sse4_1-phminposuw.c, with a few adjustments: - Adjust the dejagnu directives for powerpc platform. -

Re: [PATCH v2 6/6] rs6000: Add tests for SSE4.1 "floor" intrinsics

Hi Paul, LGTM!  Recommend maintainers approve. Bill On 7/16/21 8:50 AM, Paul A. Clarke wrote: Add the tests for _mm_floor_pd, _mm_floor_ps, _mm_floor_sd, _mm_floor_ss. These are modelled after (and depend upon parts of) the tests for _mm_ceil intrinsics, recently posted. Copy a test for

Re: [PATCH v2 1/6] rs6000: Add support for SSE4.1 "blend" intrinsics

Hi Paul, Thanks!  LGTM.  Recommend that maintainers approve. Bill On 7/16/21 8:50 AM, Paul A. Clarke wrote: _mm_blend_epi16 and _mm_blendv_epi8 were added earlier. Add these four to complete the set. 2021-07-16 Paul A. Clarke gcc * config/rs6000/smmintrin.h (_mm_blend_pd,

Re: [PATCH v2 3/6] rs6000: Add support for SSE4.1 "ceil" intrinsics

Hi Paul, Thanks for the cleanup, LGTM!  Recommend maintainers approve. Bill On 7/16/21 8:50 AM, Paul A. Clarke wrote: 2021-07-16 Paul A. Clarke gcc * config/rs6000/smmintrin.h (_mm_ceil_pd, _mm_ceil_ps, _mm_ceil_sd, _mm_ceil_ss): New. --- v2: Improve formatting per review

Re: [PATCH v2 2/6] rs6000: Add tests for SSE4.1 "blend" intrinsics

Hi Paul, Thanks for the cleanup, LGTM!  Recommend maintainers approve. Bill On 7/16/21 8:50 AM, Paul A. Clarke wrote: Copy the tests for _mm_blend_pd, _mm_blendv_pd, _mm_blend_ps, _mm_blendv_ps from gcc/testsuite/gcc.target/i386. 2021-07-16 Paul A. Clarke gcc/testsuite *

Re: [PATCH v2 5/6] rs6000: Add support for SSE4.1 "floor" intrinsics

Hi Paul, LGTM!  Recommend maintainers approve. Bill On 7/16/21 8:50 AM, Paul A. Clarke wrote: 2021-07-16 Paul A. Clarke gcc * config/rs6000/smmintrin.h (_mm_floor_pd, _mm_floor_ps, _mm_floor_sd, _mm_floor_ss): New. --- v2: Improve formatting per review from Bill.

Re: [PATCH v3 1/2] rs6000: Add support for _mm_minpos_epu16

Hi Paul, LGTM.  Recommend maintainers approve. Thanks for the cleanups, Bill On 7/15/21 6:29 PM, Paul A. Clarke wrote: Add a naive implementation of the subject x86 intrinsic to ease porting. 2021-07-15 Paul A. Clarke gcc * config/rs6000/smmintrin.h (_mm_minpos_epu16): New. ---

Re: [PATCH 23/55] rs6000: Incorporate new builtins code into the build machinery

Hi Segher, On 7/21/21 1:58 PM, Segher Boessenkool wrote: On Thu, Jun 17, 2021 at 10:19:07AM -0500, Bill Schmidt wrote: 2021-06-07 Bill Schmidt gcc/ * config.gcc (extra_objs): Include rs6000-builtins.o and rs6000-c.o. The rs6000-c.o part needs an explanation, and probably

Re: [PATCH 23/55] rs6000: Incorporate new builtins code into the build machinery

Hi Segher, On 7/27/21 9:23 AM, Segher Boessenkool wrote: On Mon, Jul 26, 2021 at 10:26:25PM -0500, Bill Schmidt wrote: Right now I just make the two generated .h files depend on the generated .c file, which works since they are all generated together or none of them are generated.  That seems

Re: [PATCH 44/55] rs6000: Builtin expansion, part 1

On 7/27/21 4:06 PM, will schmidt wrote: On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote: 2021-06-17 Bill Schmidt Hi, gcc/ * config/rs6000/rs6000-call.c (rs6000_expand_new_builtin): New forward decl. (rs6000_invalid_new_builtin): New stub

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

Hi! When introducing the new built-in support, I tried to match as many existing error messages as possible. One common form was "argument X must be a Y-bit unsigned literal". Another was "argument X must be a literal between X' and Y', inclusive". During reviews, Segher requested that I

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: [PATCH] rs6000: Fix up PCH on powerpc* [PR104323]

Hi! Jakub, thanks for fixing this.  I didn't realize the PCH implications here, clearly... On 2/1/22 12:33 PM, Segher Boessenkool wrote: > Hi! > > On Tue, Feb 01, 2022 at 04:27:40PM +0100, Jakub Jelinek wrote: >> +/* PR target/104323 */ >> +/* { dg-require-effective-target powerpc_altivec_ok }

Re: [PATCH v2 1/8] rs6000: More factoring of overload processing

Hi! On 2/1/22 3:48 PM, Segher Boessenkool wrote: > On Tue, Feb 01, 2022 at 08:49:34AM -0600, Bill Schmidt wrote: >> I've modified the previous patch to add more explanatory commentary about >> the number-of-arguments test that was previously confusing, and to convert >> the switch into an

[PATCH v3 1/8] rs6000: More factoring of overload processing

Hi! Although the previous patch was correct, the logic around what to do when the number of arguments is wrong was still hard to understand. It should be better now. I'm now explicitly counting the number of expected arguments and comparing against that. The way the argument list is

[PATCH, committed] rs6000: Clean up ISA 3.1 documentation [PR100808]

Hi! PR100808 pointed out some trivial formatting issues with Power documentation for basic ISA 3.1 built-in functions. This patch cleans those up. Tested on powerpc64le-linux-gnu, committed as obvious. Thanks! Bill 2022-02-04 Bill Schmidt gcc/ PR target/100808 *

[PATCH 6/8] rs6000: Remove -m[no-]fold-gimple flag [PR103686]

The -m[no-]fold-gimple flag was really intended primarily for internal testing while implementing GIMPLE folding for rs6000 vector built-in functions. It ended up leaking into other places, causing problems such as PR103686 identifies. Let's remove it. There are a number of tests in the

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

It was recently pointed out that we get anomalous behavior when using __attribute__((target)) to select a CPU. As an example, when building for -mcpu=power8 but using __attribute__((target("mcpu=power10")), it is legal to call __builtin_vec_mod, but not vec_mod, even though these are equivalent.

[PATCH 7/8] rs6000: vec_neg built-ins wrongly require POWER8

As the subject states. Fixing this is accomplished by moving the built-ins to the correct stanzas, [altivec] and [vsx]. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Thanks, Bill 2022-01-27 Bill Schmidt gcc/ *

[PATCH 0/8] rs6000: Built-in function cleanups and bug fixes

Hi! This is a resubmission of some patches and a new submission of others. Patches 1, 3, and 4 finish up the pending clean-up work for the new built-in infrastructure support. Patches 2 and 5-8 fix a variety of bugs not specific to the new infrastructure. I'm submitting these as a group

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

When introducing the new built-in support, I tried to match as many existing error messages as possible. One common form was "argument X must be a Y-bit unsigned literal". Another was "argument X must be a literal between X' and Y', inclusive". During reviews, Segher requested that I

[PATCH 1/8] rs6000: More factoring of overload processing

This patch continues the refactoring started with r12-6014. I had previously noted that the resolve_vec* routines can be further simplified by processing the argument list earlier, so that all routines can use the arrays of arguments and types. I found that this was useful for some of the

[PATCH 5/8] rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082]

These built-ins were misimplemented as always having big-endian semantics. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Thanks, Bill 2022-01-18 Bill Schmidt gcc/ PR target/95082 * config/rs6000/rs6000-builtin.cc

[PATCH 8/8] rs6000: Fix some missing built-in attributes [PR104004]

PR104004 caught some misses on my part in converting to the new built-in function infrastructure. In particular, I forgot to mark all of the "nosoft" built-ins, and one of those should also have been marked "no32bit". Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this

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

On 1/28/22 2:32 PM, Segher Boessenkool wrote: > On Fri, Jan 28, 2022 at 11:50:20AM -0600, Bill Schmidt wrote: >> It was recently pointed out that we get anomalous behavior when using >> __attribute__((target)) to select a CPU. As an example, when building for >> -mcpu=power8 but using

Re: [PATCH 1/8] rs6000: More factoring of overload processing

On 1/28/22 1:11 PM, Segher Boessenkool wrote: > On Fri, Jan 28, 2022 at 11:50:19AM -0600, Bill Schmidt wrote: >> This patch continues the refactoring started with r12-6014. > ab3f5b71dc6e > >> + and the generic code will issue the appropriate error message. Skip >> + this test for

Re: [PATCH 3/8] rs6000: Convert built-in constraints to form

On 1/31/22 11:28 AM, Segher Boessenkool wrote: > On Mon, Jan 31, 2022 at 11:21:32AM -0600, Bill Schmidt wrote: >> On 1/28/22 5:24 PM, Segher Boessenkool wrote: >>> On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote: When introducing the new built-in support, I tried to match as many

Re: [PATCH 3/8] rs6000: Convert built-in constraints to form

On 1/28/22 5:24 PM, Segher Boessenkool wrote: > On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote: >> When introducing the new built-in support, I tried to match as many >> existing error messages as possible. One common form was "argument X must >> be a Y-bit unsigned literal".

Re: [PATCH 4/8] rs6000: Consolidate target built-ins code

Hi Segher, On 1/31/22 3:32 PM, Segher Boessenkool wrote: > Hi! > > On Fri, Jan 28, 2022 at 11:50:22AM -0600, Bill Schmidt wrote: >> Continuing with the refactoring effort, this patch moves as much of the >> target-specific built-in support code into a new file, rs6000-builtin.cc. >> However, we

[PATCH v2 3/8] rs6000: Unify error messages for built-in constant restrictions

Hi! As discussed, I simplified this patch by just changing how the error message is produced: We currently give different error messages for built-in functions that violate range restrictions on their arguments, depending on whether we record them as requiring an n-bit literal or a literal

[PATCH v2 1/8] rs6000: More factoring of overload processing

Hi, I've modified the previous patch to add more explanatory commentary about the number-of-arguments test that was previously confusing, and to convert the switch into an if-then-else chain. The rest of the patch is unchanged. Bootstrapped and tested on powerpc64le-linux-gnu. Is this okay for

[PATCH] rs6000: Add support for vmsumcud and vec_msumc

Hi! I observed recently that a couple of Power10 instructions and built-in functions were somehow not implemented. This patch adds one of them (vmsumcud). Although this isn't normally stage-4 material, this is really simple and carries no discernible risk, so I hope it can be considered.

Re: [PATCH] rs6000: Add support for vmsumcud and vec_msumc

Hi! On 2/7/22 5:05 PM, Segher Boessenkool wrote: > Hi! > > On Mon, Feb 07, 2022 at 04:20:24PM -0600, Bill Schmidt wrote: >> I observed recently that a couple of Power10 instructions and built-in >> functions >> were somehow not implemented. This patch adds one of them (vmsumcud). >> Although

Re: [PATCH] rs6000: Add support for vmsumcud and vec_msumc

On 2/8/22 9:45 AM, Segher Boessenkool wrote: > On Mon, Feb 07, 2022 at 10:06:36PM -0600, Bill Schmidt wrote: >> On 2/7/22 5:05 PM, Segher Boessenkool wrote: >>> On Mon, Feb 07, 2022 at 04:20:24PM -0600, Bill Schmidt wrote: I observed recently that a couple of Power10 instructions and

Re: [PATCH 7/8] rs6000: vec_neg built-ins wrongly require POWER8

Hi Segher, Thanks for all the reviews for this series!  I'd like to gently ping the last two patches. BR, Bill On 1/28/22 11:50 AM, Bill Schmidt via Gcc-patches wrote: > As the subject states. Fixing this is accomplished by moving the built-ins > to the correct stanzas, [altivec] an

[PATCH] rs6000: Correct function prototypes for vec_replace_unaligned

Hi! Due to a pasto error in the documentation, vec_replace_unaligned was implemented with the same function prototypes as vec_replace_elt. It was intended that vec_replace_unaligned always specify output vectors as having type vector unsigned char, to emphasize that elements are potentially

Re: [PATCH v3] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Hi! >From some discussion today, I think we want to limit the scope of this patch to just the power8-fusion flag that's causing trouble for now, given stage 4. We've talked about making power8-fusion a do- nothing flag, since it doesn't add much benefit now and probably shouldn't be a separate

[PATCH] rs6000: Rename vec_clrl and vec_clrr to agreed-upon names

Hi! After vec_clrl and vec_clrr were implemented and during review of the documentation, it was agreed to change their names to vec_clr_first and vec_clr_last to more clearly describe their bi-endian semantics. ("Left" and "right" are the wrong terms to be using.) It looks like I neglected to

[PATCH, 11 backport] rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082]

Hi! This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac. These built-ins were misimplemented as always having big-endian semantics. Because the built-in infrastructure has changed, the modifications to the source are different but achieve the same purpose. The

Re: [PATCH, 11 backport] rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082]

Hi! On 2/10/22 2:50 PM, Segher Boessenkool wrote: > On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote: >> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac. >> These built-ins were misimplemented as always having big-endian semantics. >> >> Because the built-in

Re: [PATCH, 11 backport] rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082]

Hi! On 2/10/22 4:11 PM, Segher Boessenkool wrote: > On Thu, Feb 10, 2022 at 03:17:05PM -0600, Bill Schmidt wrote: /* 1 argument vector functions added in ISA 3.0 (power9). */ -BU_P9V_AV_1 (VCLZLSBB_V16QI, "vclzlsbb_v16qi",CONST, vclzlsbb_v16qi) -BU_P9V_AV_1 (VCLZLSBB_V8HI,

Re: [PATCH, 11 backport] rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082]

Hi! On 2/10/22 2:06 PM, Segher Boessenkool wrote: > Hi! > > On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote: >> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac. >> These built-ins were misimplemented as always having big-endian semantics. > What is different

Re: [PATCH, 11 backport] rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082]

Fine.  I withdraw the patch request, and will remove my name from the bugzilla. Somebody else can deal with it. I have more important things to worry about. Bill On 2/11/22 1:31 AM, Segher Boessenkool wrote: > Hi! > > On Thu, Feb 10, 2022 at 04:28:02PM -0600, Bill Schmidt wrote: >> On 2/10/22

Re: [PATCH] rs6000: Support vector float/double for vec_sldw

Thanks!  Pushed as r12-6806 with the testcase adjusted. Bill On 1/21/22 11:47 AM, Segher Boessenkool wrote: > Hi! > > On Fri, Jan 21, 2022 at 11:31:34AM -0600, Bill Schmidt wrote: >> It was recently discovered that Clang supports a couple of variants of >> vec_sldw that >> GCC does not. After

[PATCH] rs6000: Support vector float/double for vec_sldw

Hi, It was recently discovered that Clang supports a couple of variants of vec_sldw that GCC does not. After some discussion, we decided that these variants are reasonable, and GCC will also support them. This patch adds that support. I updated an existing test and discovered it wasn't

[PATCH] rs6000: More factoring of overload processing

Hi! This patch continues the refactoring started with r12-6014. I had previously noted that the resolve_vec* routines can be further simplified by processing the argument list earlier, so that all routines can use the arrays of arguments and types. I found that this was useful for some of the

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

Hi! It was recently pointed out that we get anomalous behavior when using __attribute__((target)) to select a CPU. As an example, when building for -mcpu=power8 but using __attribute__((target("mcpu=power10")), it is legal to call __builtin_vec_mod, but not vec_mod, even though these are

[PATCH v2] rs6000: More factoring of overload processing

Hi! [I'm resubmitting this because the filename changed with the recent conversion from .c to .cc.] This patch continues the refactoring started with r12-6014. I had previously noted that the resolve_vec* routines can be further simplified by processing the argument list earlier, so that all

<    4   5   6   7   8   9   10   >