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 4
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, "vc
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 i
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
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 modifications
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 ma
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
misal
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 Power10 instructions and built-i
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
>
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.
Bootst
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/extend
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 represented
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 if-then-
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 } *
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 betwee
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 t
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 ca
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
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". Anothe
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 __attribut
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 functi
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 o
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-bui
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 testsuit
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 (rs6000_expand
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
eventually
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.
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 routine
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 primaril
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
>> GCC does not. After s
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 actual
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 rou
Hi!
https://gcc.gnu.org/PR95082 demonstrates that we don't generate correct code for
vec_cntlz_lsbb and vec_cnttz_lsbb for little-endian targets. This patch
corrects
the problem by marking the built-ins as bif_is_endian and using the correct
target patterns for each endianness. Note that the de
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
event
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.
>
>
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
equivale
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 ro
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, then we don't provide
> the func
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! This is much clearer now.
>>
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_*) ca
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, Dec
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, which maps to an SImode pattern.
>
> So, I as
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
wrote:
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 builtins when
>>> compiled
>>> on a 32-bit arc
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 lis
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 o
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
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 th
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
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_*) ca
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 Schmi
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/
* con
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...
* con
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 a couple of patches are still pretty large.
David Edelsohn found that I had broken some C++ library functio
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
2
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 Bill Schmidt
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: Renam
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 remo
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_builtins enum
>> to
>> the rs6000_g
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 we'
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 m
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 wi
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 l
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 don
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 restricte
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 powerpc6
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. Previo
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 '__bui
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! T
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 11/1
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 su
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
Hi!
When a built-in function required by an overloaded function name is not
currently enabled, the diagnostic message is not as clear as it should be.
Saying that one built-in "requires" another is somewhat misleading. It is
better to explicitly state that the overloaded builtin is implemented by
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:
> I don't like that at all. The user didn't write
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 that is a separate
>>> issue, specific to th
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
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 restricted values. Previously this was done in many places
in an ad hoc manner, with little uniformity. Thi
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 compares. This
>> results
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 powerpc64-linux-gnu (-m32/-m64)
with no regressions. Is this okay for trunk?
Thanks!
Bill
2021-11-17 Bi
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. Previously this was done in many places
in an ad hoc manner, with little uniformity. This patch adjusts t
1 - 100 of 617 matches
Mail list logo
