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:
>
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_v1
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.
>>
&g
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
modifications to
the test suite are identical (after fixing the issue with -mbig that David
pointed out with the original patch).
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for releases/gcc-11?
Thanks!
Bill
2022-02-10 Bill Schmidt
gcc/
PR target/95082
like I neglected
to make that change, so fixing it now.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk, and for backport to gcc 11 after some burn-in?
Thanks!
Bill
2022-02-09 Bill Schmidt
gcc/
* config/rs6000/rs6000-overload.def (VEC_CLR
misaligned by this built-in function. This patch corrects the
misimplementation.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk? Eventually I would also like to backport it
to GCC 11, after burn-in.
Thanks!
Bill
2022-02-04 Bill Schmidt
gcc
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 fl
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
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 the
dered.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2022-02-07 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtins.def (VMSUMCUD): New.
* config/rs6000/rs6000-overload.def (VEC_MSUMC): New.
* config/rs6000/v
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, [altive
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
* doc
ing on the remaining special
cases, but leaves vec_splats, vec_promote, vec_extract, vec_insert, and
vec_step alone.
Thanks,
Bill
2022-02-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-c.cc (resolve_vec_mul): Accept args and types
parameters instead of arglist and nargs. Simplify
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
>>
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 } *
between two values.
It's better to be consistent. Change the error message for the n-bit
literal to look like the other one.
Bootstrapped and tested on powerpc64le-linux-gnu. Is this okay for trunk?
Thanks!
Bill
2022-01-31 Bill Schmidt
gcc/
* config/rs6000/rs6000-ca
insert, and
vec_step alone.
Thanks!
Bill
2022-01-31 Bill Schmidt
gcc/
* config/rs6000/rs6000-c.cc (resolve_vec_mul): Accept args and types
parameters instead of arglist and nargs. Simplify accordingly. Remove
unnecessary test for argument count mismatch.
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-built
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 sup
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
>> b
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
>> -
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
&
regressions.
Is this okay for trunk?
Thanks,
Bill
2022-01-27 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin.def (MFFSL): Mark nosoft.
(MTFSB0): Likewise.
(MTFSB1): Likewise.
(SET_FPSCR_RN): Likewise.
(SET_FPSCR_DRN): Mark nosoft and no32bit.
---
gcc/
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/
* config/rs6000/rs6000
gest the proper incantation for an opcode ending with a period.
Bootstrapped and tested on powerpc64le-linux-gnu and on
powerpc64-linux-gnu (32- and 64-bit) with no regressions.
Is this okay for trunk?
Thanks,
Bill
2022-01-27 Bill Schmidt
gcc/
PR target/103686
* config/rs6000/rs
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
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?
Thanks,
Bill
2022
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 with no regressions.
Is this okay for trunk?
Thanks,
Bill
2022-01-06 Bill Schm
d and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?
Thanks,
Bill
2022-01-18 Bill Schmidt
gcc/
* config/rs6000/rs6000-c.cc (resolve_vec_mul): Accept args and types
parameters instead of arglist and nargs. Simplify accordingly. Remove
unnec
group primarily because
5-8 are dependent on the previous patches, particularly patch 4, which
consolidates much of the built-in code in a new file.
Thanks for your consideration!
Bill
Bill Schmidt (8):
rs6000: More factoring of overload processing
rs6000: Don't #ifdef "short" bui
Adding the patch author for his information.
Thanks,
Bill
On 1/24/22 2:26 PM, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Jan 24, 2022 at 08:55:37AM -0600, Segher Boessenkool wrote:
>> Hi!
>>
>> On Thu, Jan 13, 2022 at 02:08:53PM -0300, Raoni Fassina Firmino wrote:
>>> Changes since v8[8]:
>>>
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
&g
x27;t actually checking for
generation
of the xxsldwi instruction, so I added that check as well.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay
for trunk?
Thanks!
Bill
2022-01-21 Bill Schmidt
gcc/
* config/rs6000/rs6000-overload.def (VEC_SLDW)
al
cases, but leaves vec_splats, vec_promote, vec_extract, vec_insert, and
vec_step alone.
Bootstrapped and tested on powerpc64le-linux-gnu. Is this okay for trunk?
Thanks,
Bill
2022-01-18 Bill Schmidt
gcc/
* config/rs6000/rs6000-c.cc (resolve_vec_mul): Accept args and types
p
t the default patterns are for
little endian, and the overridden patterns in rs6000-builtin.cc are for big
endian.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk, and eventually for backport to GCC 11?
Thanks!
Bill
2022-01-18 Bill Schmidt
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?
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:
>
>>
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.
>
>
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/
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
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,
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
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
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
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
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.
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
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)
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
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
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
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
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
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
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
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
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
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
ointer when the situation
arises.
Tested the fix on a powerpc-e300c3-linux-gnu cross. Bootstrapped and tested on
powerpc64le-linux-gnu with no regressions. Is this okay for trunk?
Thanks!
Bill
2021-12-13 Bill Schmidt
gcc/
PR target/103622
* config/rs6000/rs6000-c.c (altivec_resol
on a powerpc-e300c3-linux-gnu cross. Bootstrapped and tested on
powerpc64le-linux-gnu with no regressions. Is this okay for trunk?
Thanks!
Bill
2021-12-13 Bill Schmidt
gcc/
PR target/103625
* config/rs6000/rs6000-builtin-new.def (__builtin_altivec_vcmpequd):
Move to
e fix on a powerpc-e300c3-linux-gnu cross. Bootstrapped and tested on
powerpc64le-linux-gnu with no regressions. Is this okay for trunk?
Thanks!
Bill
2021-12-13 Bill Schmidt
gcc/
PR target/103623
* config/rs6000/rs6000-builtin-new.def (__builtin_pack_longdouble): Add
the problem.
Tested the fix on a powerpc-e300c3-linux-gnu cross. Bootstrapped and tested on
powerpc64le-linux-gnu with no regressions. Is this okay for trunk?
Thanks!
Bill
2021-12-13 Bill Schmidt
gcc/
PR target/103624
* config/rs6000/rs6000-builtin-new.def (__builtin_darn
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
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)
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 tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-06 Bill
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 Schm
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 for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin.def: Delete
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?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def: Rename to
functions for AIX, and
his fix for that required me to re-spin the patches. I also generated the diff
with a more efficient algorithm to reduce the patch size. Otherwise this
series is identical to V1.
Thanks!
Bill
Bill Schmidt (6):
rs6000: Remove new_builtins_are_live and dead code it was guarding
I had difficulty with patch 1/6 being too large, and there have been some small
upstream changes in this area, so I will resubmit this series shortly. There
were also problems with my SMTP server for some of the CCs as well...
Sorry for the churn!
Bill
On 12/3/21 12:22 PM, Bill Schmidt wrote
From: Bill Schmidt
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 tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
From: Bill Schmidt
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 Bi
From: Bill Schmidt
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?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def
From: Bill Schmidt
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 avoid confusion. I broke this
up to the extent possible, but the first patch is a bit large and messy because
so many dead functions have to be
On 12/3/21 10:26 AM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 02, 2021 at 04:53:18PM -0600, Bill Schmidt wrote:
>> I discovered this bug while working on patches to remove the old built-ins
>> infrastructure. I missed a spot in converting from the rs6000_builti
we're not going to do
that anymore, and the remnants of that code will be removed shortly.
Regstrap is in progress on powerpc64le-linux-gnu. Assuming no problems, is this
okay to commit to trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6
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 builti
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 erro
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
>
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
>> unavaila
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
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 power
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 wi
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 dec
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 w
On 11/16/21 12:56 PM, 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 like to submit this for consideration.
>
> We eventuall
-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-01 Bill Schmidt
gcc/
PR target/102347
* config/rs6000/rs6000-c.c (rs6000-builtins.h): Stop including.
(rs6000-internal.h): Include.
(altivec_resolve_new_overloaded_builtin): Mo
Hi!
Paul Clarke pointed out to me that I had wrongly used a compile-time check
instead of a run-time check in this executable test. This patch fixes
that. I also fixed a typo in a string that caught my eye.
Tested on powerpc64le-linux-gnu, committed as obvious.
Thanks!
Bill
2021-11-23 Bill
suite, since we
don't test for "note" diagnostics anywhere.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is
this okay for trunk?
Thanks!
Bill
2021-11-23 Bill Schmidt
gcc/
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builti
Hi Mike,
Thanks for this patch!
On 11/19/21 8:53 AM, Michael Meissner wrote:
> Add power10 zero cycle moves for switches.
>
> Power10 will fuse adjacenet 'mtctr' and 'bctr' instructions to form zero
> cycle moves. This code exploits this fusion opportunity.
>
> I have built bootstrapped compiler
Hi Mike,
On 11/19/21 8:55 AM, Michael Meissner wrote:
> Set power10 fusion if -mtune=power10.
>
> In doing the patch for zero cycle moves for switch statements and indirect
> jumps, I noticed the fusion support is only done if -mcpu=power10. This
> option
> enables power10 fusion if we use -mtun
Hi!
On 11/19/21 8:49 AM, Michael Meissner wrote:
> The next set of 3 patches add zero cycle move support to the Power10. Zero
> cycle moves are where the move to LR/CTR/TAR register that is adjacent to the
> jump to LR/CTR/TAR register can be fused together.
>
> At the moment, these set of three
Hi!
On 11/18/21 3:32 PM, Segher Boessenkool wrote:
> On Thu, Nov 18, 2021 at 03:30:48PM -0600, Bill Schmidt wrote:
>> On 11/18/21 3:16 PM, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Wed, Nov 17, 2021 at 05:06:05PM -0600, Bill Schmidt wrote:
>>>>&g
On 11/18/21 3:16 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 17, 2021 at 05:06:05PM -0600, Bill Schmidt wrote:
>>> I don't like that at all. The user didn't write the _vsx thing, and it
>>> isn't documented either (neither is the _vec one, but
Hi! Thanks for all the recent reviews and conversations on the builtins
infrastructure patches. I've posted a lot of stuff in the last couple
of days, so I thought it might be useful to summarize which patches still
need review. No rush, just trying to make it easier to consume...
https://gcc.g
messages. In
particular, some messages are improved because previously they did not
admit the possibility that an argument could hold a variable.
Tested on powerpc64le-linux-gnu and powerpc64-linux-gnu (-m32/-m64)
with no regressions. Is this okay for trunk?
Thanks!
Bill
2021-11-17 Bill Schmid
Hi!
On 11/18/21 10:22 AM, Segher Boessenkool wrote:
> On Thu, Nov 18, 2021 at 10:09:53AM -0600, Bill Schmidt wrote:
>> Hi! This patch is broken out from the test case patch for the new builtins
>> support.
>>
>> The old builtins code performs gimple folding on 128-bit
Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/pragma_misc9.c: Adjust error message.
---
gcc/testsuite/gcc.target/powerpc/pragma_misc9.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pragma_misc9.c
b/gcc/testsuite/gcc.target
owerpc64le-linux-gnu and powerpc64-linux-gnu (-m32/-m64) with
no regressions. is this okay for trunk?
Thanks!
Bill
2021-11-17 Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/pr80315-1.c: Adjust error message.
* gcc.target/powerpc/pr80315-2.c: Likewise.
*
1 - 100 of 1523 matches
Mail list logo
