On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote:
> On Mon, Sep 19, 2022 at 11:13:20AM -0500, will schmidt wrote:
> > The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
> > and can be disabled by dependent options when it should not be.
> > This manifests in the issue seen in
On Mon, 2022-10-17 at 10:32 -0500, Segher Boessenkool wrote:
> Hi!
>
> Everything Ke Wen said. Some more commments / hints:
Thanks for the reviews. :-)
I'll rework things and repost 'soon'.
Thanks
-WIll
Ping.
On Mon, 2022-09-19 at 11:13 -0500, will schmidt wrote:
> [PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865]
>
> Hi,
> The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
> and can be disabled by dependent options when it should not be.
> This manifests in
[PATCH, rs6000] Fix addg6s builtin with long long parameters. (PR100693)
Hi,
As reported in PR 100693, attempts to use __builtin_addg6s
with long long arguments result in truncated results.
Since the int and long long types can be coerced into each other,
(documented further near the
On Fri, 2022-09-30 at 09:20 +0200, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Sep 28, 2022 at 08:19:43PM +0200, Jakub Jelinek via Gcc-
> patches wrote:
> > Another case are the following 3 snippets:
> > # if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> > # error "_Float128X supported but
On Tue, 2022-09-20 at 16:14 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Sep 19, 2022 at 06:19:15PM -0500, will schmidt wrote:
> > This is the first of a batch of changes that eliminate a number
> > of define TARGET_foo entries we have collected over time.
>
> Good good :-)
>
> >
[PATCH, rs6000] Eliminate TARGET_CTZ,TARGET_FCTIDZ,FCTIWUZ defines
Hi,
This is the first of a batch of changes that eliminate a number
of define TARGET_foo entries we have collected over time.
TARGET_CTZ is defined as TARGET_MODULO, and has a low number
of uses. References to TARGET_CTZ
[PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865]
Hi,
The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
and can be disabled by dependent options when it should not be.
This manifests in the issue seen in PR101865 where -mno-vsx
mistakenly disables _ARCH_PWR8.
[PATCH, rs6000] Tests of ARCH_PWR8 and -mno-vsx option.
Hi,
This adds an assortment of tests to exercise the -mno-vsx option and
confirm the impacts on the ARCH_PWR8 define.
These are based on and inspired by PR 101865, which
reports that _ARCH_PWR8 is disabled when -mno-vsx
is passed on the
[PATCH, rs6000, v2] Cleanup some vstrir define_expand naming inconsistencies
Hi,
This cleans up some of the naming around the vstrir and vstril
instruction definitions, with some cosmetic changes for consistency.
No functional changes.
Regtested just in case, no regressions.
[V2]
Used 'direct'
[PATCH, rs6000, v2] Additional cleanup of rs6000_builtin_mask
Hi,
Post the rs6000 builtins rewrite, some of the leftover builtin
code is redundant and can be removed.
This replaces the usage of bu_mask in rs6000_target_modify_macros
with checks against the rs6000_isa_flags equivalent
On Thu, 2022-07-14 at 11:28 +0800, Kewen.Lin wrote:
> Hi Will,
>
> Thanks for the cleanup! Some comments are inlined.
Hi,
Thanks for the review. A few comments and responses below. TLDR I'll
incorporate the suggestions in V2 that will show up ... after. :-)
>
> on 2022/7/14 05:39, will
[PATCH, rs6000] Additional cleanup of rs6000_builtin_mask
Hi,
Post the rs6000 builtins rewrite, some of the leftover builtin
code is redundant and can be removed.
This replaces the remaining usage of bu_mask in
rs6000_target_modify_macros() with checks against the rs6000_cpu directly.
On Wed, 2022-07-13 at 14:39 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 13, 2022 at 01:18:29PM -0500, will schmidt wrote:
> > This cleans up some of the naming around the vstrir and vstril
> > instruction definitions, with some cosmetic changes for
> > consistency.
> > gcc/
> > *
[PATCH, rs6000] Cleanup some vstrir define_expand naming inconsistencies
Hi,
This cleans up some of the naming around the vstrir and vstril
instruction definitions, with some cosmetic changes for consistency.
No functional changes.
Regtested just in case, no regressions. :-)
OK for trunk?
On Tue, 2022-06-07 at 23:16 -0400, Michael Meissner wrote:
> On Tue, Jun 07, 2022 at 07:59:34PM -0500, Peter Bergner wrote:
> > On 6/7/22 4:24 PM, Segher Boessenkool wrote:
> > > On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote:
> > > > I think I mentioned this offline, but I'd prefer
On Tue, 2022-06-07 at 15:21 -0500, Segher Boessenkool wrote:
> On Tue, Jun 07, 2022 at 02:26:17PM -0500, will schmidt wrote:
> > On Mon, 2022-06-06 at 20:31 -0400, Michael Meissner wrote:
> > > (define_insn "vsx_xxspltd_"
> > >[(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa")
> > > -
On Mon, 2022-06-06 at 20:56 -0400, Michael Meissner wrote:
> [PATCH 3/3] Adjust MMA tests to account for no store vector pair.
>
> In changing the default for generating the store vector pair instructions,
> I had to adjust several of the MMA tests to remove checking for these
> instructions.
On Mon, 2022-06-06 at 20:55 -0400, Michael Meissner wrote:
> [PATCH 1/3] Disable generating store vector pair.
>
> Testing has revealed that the power10 has some slowdowns if the store
> vector pair instruction is generated in some cases. This patch disables
> generating the store vector pair
On Mon, 2022-06-06 at 20:55 -0400, Michael Meissner wrote:
> [PATCH 2/3] Disable generating load/store vector pairs for block copies.
>
> If the store vector pair instruction is disabled, do not generate block
> copies that use load and store vector pair instructions.
>
> I have built bootstrap
On Mon, 2022-06-06 at 20:31 -0400, Michael Meissner wrote:
> Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target
> 99293.
>
> This is version 3 of the patch. The original patch was:
>
> > Date: Mon, 28 Mar 2022 12:26:02 -0400
> > Subject: [PATCH 1/4] Optimize vec_splats of
On Tue, 2022-06-07 at 10:50 +0800, Kewen.Lin wrote:
> Hi Will,
Hi!
>
> The whole series looks good to me, thanks!
:-)
> IMHO one place can be
> further
refactored, not sure if it's worth to updating together in
> this series, it's ...
Additional comments
[PATCH,RS6000 4/5] Replace MASK_ with OPTION_MASK_
This replaces the MASK_ references with OPTION_MASK_
and removes the now unused defines.
This patch removes the defines for
MASK_ALTIVEC, MASK_CMPB, MASK_CRYPTO, MASK_DFP,
MASK_DIRECT_MOVE, MASK_DLMZB, MASK_EABI, MASK_FLOAT128_KEYWORD,
[PATCH,RS6000 5/5] Replace MASK_ usage with OPTION_MASK_
This continues the changes of replacing the MASK_ defines
with their OPTION_MASK_ equivalents.
This patch removes the defines for
MASK_P8_VECTOR, MASK_P9_VECTOR, MASK_P9_MISC, MASK_POPCNTB,
MASK_POPCNTD, MASK_PPC_GFXOPT, MASK_PPC_GPOPT,
[PATCH, RS6000 3/5] Rework the RS6000_BTM defines, continued.
The RS6000_BTM_ definitions are mostly unused after
the rs6000 builtin code was reworked. This cleans
up the remaining RS6000_BTM_ references by replacing
them with their OPTION_MASK_ equivalents.
This patch removes the defines
[PATCH,RS6000 2/5) Rework the RS6000_BTM defines.
The RS6000_BTM_ definitions are mostly unused after the rs6000
builtin code was reworked. The remaining references can be replaced
with the OPTION_MASK_ and MASK_ equivalents.
This patch remvoes the defines:
RS6000_BTM_FRES, RS6000_BTM_FRSQRTE,
[PATCH,RS6000 1/5] Clean-up MASK_ and RS6000_BTM_ definitions.
Hi,
This patch removes the defines that are no longer used, and
updates the comment for the set of MASK_ defines.
This patch removes the defines for
MASK_REGNAMES, MASK_PROTOTYPE, RS6000_BTM_ALWAYS, RS6000_BTM_COMMON.
gcc/
Hi,
This series cleans up the assorted MASK_, OPTION_MASK_,
and RS6000_BTM_ defines that we have sprinkled through the
rs6000 target code.
The MASK_ entries are currently defined as their OPTION_MASK_
equivalents since their introduction when the rs6000_isa_flags was
added via commit
On Thu, 2022-05-26 at 13:31 -0500, Segher Boessenkool wrote:
> > >
> On Thu, May 26, 2022 at 09:40:18AM -0500, will schmidt wrote:
> > On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote:
>
> > I'll dig a bit more, but would handle that in a separate
> > patch.
>
> Can you please
> on 2022/5/26 04:25, will schmidt via Gcc-patches wrote:
> > > > We have an assortment of MASK and OPTION_MASK #defines
> > > > throughout
> > > > the rs6000 code, MASK_ALTIVEC and OPTION_MASK_ALTIVEC as an
> > > > example.
> > >
[PATCH, rs6000] Clean up the option_mask defines (part 3)
Hi,
Per code review, the MASK_REGNAMES, OPTION_MASK_REGNAMES,
MASK_PROTOTYPE, OPTION_MASK_PROTOTYPE options are not used
elsewhere in the codebase. Thus it should be safe to remove them.
This includes an update to a nearby comment to
[PATCH, rs6000] Clean up the option_mask defines (part 2)
Hi,
This patch reworks most of the lingering MASK_*
values to OPTION_MASK_* and removes the now redundant defines.
Regtested OK on power10. OK for trunk?
gcc/
* rs6000.h (RS6000_BTM_VSX, RS6000_BTM_P8_VECTOR,
[PATCH, rs6000] Clean up the option_mask defines
Hi,
We have an assortment of MASK and OPTION_MASK #defines throughout
the rs6000 code, MASK_ALTIVEC and OPTION_MASK_ALTIVEC as an example.
We currently #define the MASK_ entries to their OPTION_MASK_
equivalents so the two names could be used
On Tue, 2022-05-17 at 23:15 -0400, Michael Meissner wrote:
> On Fri, May 13, 2022 at 01:20:30PM -0500, will schmidt wrote:
> > On Fri, 2022-05-13 at 12:17 -0400, Michael Meissner wrote:
> > >
> > >
> > > gcc/
> > > PR target/103109
> > > * config/rs6000/rs6000.md (su_int32): New code
[PATCH, rs6000] Remove the (no longer used) RS6000_BTC defines.
Hi,
These defines are no longer used once the rs6000 built-in
reworks were completed. Would be good to remove them.
There was a reference to RS6000_BTC_SPECIAL in a TODO comment
in rs6000-builtins.def. That comment remains, but
On Fri, 2022-05-13 at 12:19 -0400, Michael Meissner wrote:
> Generate vadduqm and vsubuqm for TImode add/subtract
>
> If the TImode variable is in an Altivec register instead of a GPR
> register, then generate vadduqm and vsubuqm instead of having to move the
> value to the GPR registers and
On Fri, 2022-05-13 at 12:17 -0400, Michael Meissner wrote:
> Optimize multiply/add of DImode extended to TImode, PR target/103109.
>
> On power9 and power10 systems, we have instructions that support doing
> 64-bit integers converted to 128-bit integers and producing 128-bit
> results. This
On Fri, 2022-05-13 at 12:13 -0400, Michael Meissner wrote:
> Add zero_extendditi2. Improve lxvr*x code generation.
>
Content here matches what I commented on in the prior email with
subject "Delay splitting addti3...".
> This pattern adds zero_extendditi2 so that if we are extending
On Fri, 2022-05-13 at 11:08 -0400, Michael Meissner wrote:
> Add zero_extendditi2. Improve lxvr*x code generation.
>
Hi,
> Subject: Re: [PATCH] Delay splitting addti3/subti3 until first split
pass.
Subject does not seem to match contents?
> This pattern adds zero_extendditi2 so that if
On Fri, 2022-05-13 at 10:52 -0400, Michael Meissner wrote:
> Replace UNSPEC with RTL code for extendditi2.
>
Hi,
> When I submitted my patch on March 12th for extendditi2, Segher
> wished I
> had removed the use of the UNSPEC for the vextsd2q instruction. This
> patch rewrites
On Fri, 2022-05-13 at 10:49 -0400, Michael Meissner wrote:
> Optimize vec_splats of constant V2DI/V2DF vec_extract, PR target/99293.
>
> This patch has been previously posted, but it seemed to get lost.:
>
> > Date: Tue, 29 Mar 2022 23:25:31 -0400
> > Subject: [PATCH, V2] Optimize vec_splats of
On Tue, 2022-04-12 at 21:14 -0400, Michael Meissner wrote:
> Eliminate power8 fusion options, use power8 tuning, PR target/102059
>
> This is V4 of the patch. Compared to V3 of the patch, GCC will just
> ignore -m{,no-}power8-fusion and -m{,no-}power8-fusion-sign.
>
Hi,
No comments on code,
On Mon, 2022-02-28 at 11:17 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn on
> each subtarget after mode promotion is disabled. The patch need to
On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the
> complete unrolling can happen on some of its loops. This patch is to
> use pragma "GCC unroll 0" to disable all possible loop unrollings.
> Hope
On Thu, 2022-04-07 at 06:00 -0500, Segher Boessenkool wrote:
> On Thu, Apr 07, 2022 at 12:29:45AM -0400, Michael Meissner wrote:
> > In PR target/104253, it was pointed out the that test case added as part
> > of fixing the PR does not work on VxWorks because float128 is not
> > supported on that
On Thu, 2022-04-07 at 17:29 +0800, Kewen.Lin wrote:
> Hi,
>
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions. As shown in
> that PR, without one
On Wed, 2022-04-06 at 14:21 -0400, Michael Meissner wrote:
> From bf51c49f1481001c7b3223474d261dcbf9365eda Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Fri, 1 Apr 2022 22:27:13 -0400
> Subject: [PATCH] Add zero_extendditi2. Improve lxvr*x code generation.
>
Hi,
> This pattern
On Thu, 2022-03-03 at 16:38 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
Hi
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions. As shown in
> that
On Fri, 2022-01-28 at 11:50 -0600, Bill Schmidt via Gcc-patches wrote:
> 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
On Mon, 2022-03-21 at 09:51 +0800, HAO CHEN GUI wrote:
> Hi,
>This patch adds V1TI mode into a new mode iterator used in vector
> comparison expands.Without the patch, the comparisons between two vector
> __int128 are converted to scalar comparisons with branches. The code is
> suboptimal.The
On Thu, 2022-03-17 at 13:35 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>This patch adds V1TI mode into a new mode iterator used in vector
> comparison expands.With the patch, both built-ins and direct
> comparison
> could generate P10 new V1TI comparison instructions.
Hi,
-/* We
On Wed, 2022-03-16 at 13:12 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Mar 16, 2022 at 12:20:18PM -0500, will schmidt wrote:
> > For PR100693, we currently provide an addg6s builtin using unsigned
> > int arguments, but we are missing an unsigned long long argument
> > equivalent. This
Hi,
RFC/Update support for addg6s instruction. PR100693
For PR100693, we currently provide an addg6s builtin using unsigned
int arguments, but we are missing an unsigned long long argument
equivalent. This patch adds an overload to provide the long long
version of the builtin.
unsigned long
On Thu, 2022-03-10 at 13:49 -0600, Segher Boessenkool wrote:
> On Thu, Mar 10, 2022 at 10:44:52AM -0600, will schmidt wrote:
> > On Wed, 2022-03-09 at 22:49 -0500, Michael Meissner wrote:
> > > --- a/gcc/config/rs6000/rs6000-cpus.def
> > > +++ b/gcc/config/rs6000/rs6000-cpus.def
> > > @@ -43,9
On Wed, 2022-03-09 at 22:49 -0500, Michael Meissner wrote:
> Eliminate power8 fusion options, use power8 tuning, PR target/102059
Hi,
>
> The power8 fusion support used to be set automatically when -mcpu=power8 or
> -mtune=power8 was used, and it was cleared for other cpu's. However, if you
>
On Mon, 2022-02-28 at 22:21 -0500, Michael Meissner wrote:
> Optimize signed DImode -> TImode on power10, PR target/104698.
>
Hi,
Logic seems OK to me, a few suggestions on the comments intermixed
below. As always, i defer if there are counter arguments. :-)
> On power10, GCC tries to
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
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,
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
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
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
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
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
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
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.
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
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
*
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
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
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
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
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
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".
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
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
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
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/
*
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 902 matches
Mail list logo
