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 manife
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.
&
[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
[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
2022/7/14 05:39, will schmidt wrote:
> > [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
[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
>
[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_operan
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
dditional comments below.
I've made note of the comments, and request (ask) that this be
approved, with a pinky promise that I intend to follow up on the
suggestions in my next patch series.
>
> on 2022/6/7 06:05, will schmidt wrote:
> > [PATCH,RS6000 2/5) Rework the RS6000_BTM def
[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
>
> 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
> >
, but I have updated
the comment to refer to "SPECIAL" processing, instead of having it
refer directly to the RS6000_BTC_SPECIAL macro.
2022-05-17 Will Schmidt
gcc/
* config/rs6000/rs6000-builtins.def: rephrase
RS6000_BTC_SPECIAL in comment.
* config/rs6000/rs6000.
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 ar
power8,power9,power10.
2022-03-15 Will Schmidt
gcc/
PR target/100693
* config/rs6000/rs600-builtins.def: Remove entry for __builtin_addgs()
and add entries for __builtin_addg6s_di() and __builtin_addg6s_si().
* config/rs6000/rs6000-overload.def: Add overloaded
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/rs6
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:
>
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.
>>
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
. The 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
oks 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
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
.
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/vsx.md
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
* doc
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 accordingly. Remove
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 conver
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-call.cc
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.
(resolve_vec_cmpne
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. Sk
with no 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
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/rs6000-builtin.cc
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-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-01-12 Bill Schmidt
g
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
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
unnecessary test
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" built-in name
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
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): Add
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
parameters instead
that 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
gcc
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-01-12
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/
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
unnecessary test
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 d
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 4606 matches
Mail list logo
