This patch fixes an issue where if you use the -fstack-protector and
-mcpu=power10 options and you have a large stack frame, the GCC compiler will
generate a LWA instruction with a large offset.
Unlike the previous versions of this patch, I dug into it, and I found it was
much more complex that I
Ping patch:
| Date: Mon, 10 Jul 2023 15:50:47 -0400
| From: Michael Meissner
| Subject: [PATCH] Optimize vec_splats of vec_extract for V2DI/V2DF (PR
target/99293)
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patch.
| Date: Mon, 10 Jul 2023 15:51:56 -0400
| From: Michael Meissner
| Subject: [PATCH] Improve 64->128 bit zero extension on PowerPC (PR
target/108958)
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping clean-up patch.
| Date: Mon, 10 Jul 2023 15:59:44 -0400
| From: Michael Meissner
| Subject: [PATCH] Fix typo in insn name.
| Message-ID:
As I said in the reply, the only thing this patch does is to rename
vsx_extract_v4sf__load to vsx_extract_v4sf_load since the insn does not
use a mode it
On Wed, Jul 26, 2023 at 01:54:01PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> on 2023/7/11 03:59, Michael Meissner wrote:
> > In doing other work, I noticed that there was an insn:
> >
> > vsx_extract_v4sf__load
> >
> > Which did not have an iterator. I removed the useless .
>
> It actually ha
I have applied the patch to GCC 12.
| From 22736f3d0d4fb8ce4afb3230023f8accdb03a623 Mon Sep 17 00:00:00 2001
| From: Michael Meissner
| Date: Thu, 14 Jul 2022 11:16:08 -0400
| Subject: [PATCH] [BACKPORT] Disable generating load/store vector pairs for
block copies.
Testing has found that using l
Back port patch (changing .cc to .c) from trunk to GCC 11 committed.
| From 3118d0856b030fe491a170354fed2df570df199f Mon Sep 17 00:00:00 2001
| From: Michael Meissner
| Date: Thu, 14 Jul 2022 14:03:37 -0400
| Subject: [PATCH] [BACKPORT] Disable generating load/store vector pairs for
block copies
On Thu, Jul 14, 2022 at 04:12:14PM -0500, Segher Boessenkool wrote:
> On Thu, Jul 14, 2022 at 11:20:56AM -0400, Michael Meissner wrote:
> > I have applied the patch to GCC 12.
> >
> > | From 22736f3d0d4fb8ce4afb3230023f8accdb03a623 Mon Sep 17 00:00:00 2001
> > | From: Michael Meissner
> > | Date:
Remove setting -mblock-ops-vector-pair on power10.
Testing has shown that using the load vector pair and store vector pair
instructions for block moves has some performance issues on power10. This
patch does not set this option by default. If it is a win in other
machines in the future, this fla
Do not enable -mblock-ops-vector-pair.
Testing has shown that using the load vector pair and store vector pair
instructions for block moves has some performance issues on power10.
A patch on June 11th modified the code so that GCC would not set
-mblock-ops-vector-pair by default if we are tuning
The following patches add support for doing built-in function overloading
between the two 128-bit IEEE types (i.e. _Float182/__float128 using KFmode and
when long double uses the IEEE 128-bit encoding with TFmode).
These patches lay the foundation for a set of follow-on patches that will
change th
[PATCH 1/5] IEEE 128-bit built-in overload support.
This patch lays the ground work that future patches will use to add
builtin support (both normal and overloaded) for the case where long
double uses the IEEE 128-bit encoding.
This adds a new stanza (ieee128-hw-ld) for when we have IEEE 128-bit
[PATCH 2/5] Support IEEE 128-bit overload round_to_odd built-in functions.
This patch adds support for overloading the IEEE 128-bit round to odd
built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults to using lon
PATCH 3/5] Support IEEE 128-bit overload comparison built-in functions.
This patch adds support for overloading the IEEE 128-bit comparison
built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long dou
[PATCH 4/5] Support IEEE 128-bit overload extract and insert built-in functions.
This patch adds support for overloading the IEEE 128-bit extract and
insert built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults
[PATCH 5/5] Support IEEE 128-bit overload test data built-in functions.
This patch adds support for overloading the IEEE 128-bit test data and
test data negate built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaul
Ping patch.
| Date: Mon, 25 Jul 2022 16:15:05 -0400
| Subject: [PATCH, V2] Do not enable -mblock-ops-vector-pair.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patches.
Patch #1 of 5.
| Date: Thu, 28 Jul 2022 00:47:13 -0400
| Subject: [PATCH 1/5] IEEE 128-bit built-in overload support.
| Message-ID:
Patch #2 of 5.
| Date: Thu, 28 Jul 2022 00:48:51 -0400
| Subject: [PATCH 2/5] Support IEEE 128-bit overload round_to_odd built-in
functions.
| Messag
On Fri, Aug 05, 2022 at 01:19:05PM -0500, Segher Boessenkool wrote:
> On Thu, Jul 28, 2022 at 12:43:49AM -0400, Michael Meissner wrote:
> > These patches lay the foundation for a set of follow-on patches that will
> > change the internal handling of 128-bit floating point types in GCC. In the
> >
I get the following warning which prevents gcc from bootstrapping due to
-Werror:
/home/meissner/fsf-src/work124-sfsplat/gcc/config/rs6000/rs6000-p10sfopt.cc: In
function ‘void {anonymous}::process_chain_from_load(gimple*)’:
/home/meissner/fsf-src/work124-sfsplat/gcc/config/rs6000/rs6000-p10sfopt
This patch optimizes cases like:
vector double v1, v2;
/* ... */
v2 = vec_splats (vec_extract (v1, 0); /* or */
v2 = vec_splats (vec_extract (v1, 1);
Previously:
vector long long
splat_dup_l_0 (vector long long v)
{
return __bu
If we are converting an unsigned DImode to a TImode value, and the TImode value
will go in a vector register, GCC currently does the DImode to TImode conversion
in GPR registers, and then moves the value to the vector register via a mtvsrdd
instruction.
This patch adds a new zero_extendditi2 insn
In doing other work, I noticed that there was an insn:
vsx_extract_v4sf__load
Which did not have an iterator. I removed the useless .
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE, --with-cpu=powe
I forgot to add:
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE, --with-cpu=power10, IBM 128-bit long double
* Power9, LE, --with-cpu=power9, IBM 128-bit long double
* Power9, LE, --with-cpu=po
I forgot to add:
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE, --with-cpu=power10, IBM 128-bit long double
* Power9, LE, --with-cpu=power9, IBM 128-bit long double
* Power9, LE, --with-cpu=po
On Mon, Jul 10, 2023 at 03:10:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jul 10, 2023 at 03:59:44PM -0400, Michael Meissner wrote:
> > In doing other work, I noticed that there was an insn:
> >
> > vsx_extract_v4sf__load
> >
> > Which did not have an iterator. I removed the use
On Wed, Feb 22, 2023 at 06:13:07PM +0800, Kewen.Lin wrote:
> These two above paragraphs look a bit out of date (two patches now). :)
Thanks.
> IIUC this patch actually fixes a latent issue, so it is independent of the one
> fixing the bootstrapping issue, right? This updated version of patch loo
On Wed, Feb 22, 2023 at 06:37:39PM +0800, Kewen.Lin wrote:
> Thanks for working on this! If updating libgcc source to workaround this
> issue
> is the best option we can have at this moment, it's fine.
Thanks. Yes, I agree that it does not fix the root issue.
> Comparing to one
> previous prop
This is the most important patch to look at:
| Date: Wed, 14 Dec 2022 15:29:02 -0500
| From: Michael Meissner
| Subject: [PATCH, V3] PR 107299, GCC does not build on PowerPC when long
double is IEEE 128-bit
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
emai
This is the most important patch. It is needed to allow the boostrap to work
again when long double is IEEE 128-bit.
| Date: Fri, 3 Feb 2023 00:49:12 -0500
| From: Michael Meissner
| Subject: [PATCH 1/2] PR target/107299: Fix build issue when long double is
IEEE 128-bit
| Message-ID:
--
Mich
This patch is second in importance after the first patch in the series. It is
needed to allow complex IBM 128-bit multiply/divide when long double is IEEE
128-bit.
| Date: Fri, 3 Feb 2023 00:53:05 -0500
| From: Michael Meissner
| Subject: [PATCH 2/2] Rework 128-bit complex multiply and divide.
|
On Fri, Mar 03, 2023 at 03:35:44PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Feb 03, 2023 at 12:53:05AM -0500, Michael Meissner wrote:
> > This patch reworks how the complex multiply and divide built-in functions
> > are
> > done.
>
> > I tested all 3 patchs for PR target/107299 on:
>
On Fri, Mar 03, 2023 at 03:35:44PM -0600, Segher Boessenkool wrote:
> > +complex_multiply_builtin_code (machine_mode mode)
> > +{
> > + return (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + mode
> > + - MIN_MODE_COMPLEX_FLOAT);
> > +}
>
> There should be an assert that th
On Thu, Mar 09, 2023 at 04:16:21PM -0600, Segher Boessenkool wrote:
> On Thu, Mar 09, 2023 at 11:11:34AM -0500, Michael Meissner wrote:
> > On Fri, Mar 03, 2023 at 03:35:44PM -0600, Segher Boessenkool wrote:
> > > > +/* { dg-final { scan-assembler "bl __divtc3" } } */
> > >
> > > This name depends
This patch reworks how the complex multiply and divide built-in functions are
done. Previously GCC created built-in declarations for doing long double
complex
multiply and divide when long double is IEEE 128-bit. However, it did not
support __ibm128 complex multiply and divide if long double is
I have posted 4 previous versions of this patch (April 26th, March 28th, March
24th, and March 21st).
In this patch, rather than just add changes to the existing code in
genfusion.pl, I rewrote the function completely. There are two patches within
this patch set:
* The first patch rewrites t
This patch rewrites the gen_ld_cmpi_p10 function in genfusion.pl to be clearer.
The resulting fusion.md file that this patch generates is exactly the same
output that the previous version of genfusion.pl generated. The next patch in
this series will fix PR target/105325 (provide correct predicates
This patch applies stricter predicates and constraints for LD and LWA
instructions with power10 fusion. These instructions are DS-form instructions,
which means that the bottom 2 bits of the address must be 0. In the past, we
did not use the stricter predicates and constraints, and if the user us
Ping both patches:
Patch #1, rewrite genfusion.pl's code for load and compare immediate fusion to
be more readable. This patch produces the same output as the current sources.
| Date: Wed, 10 May 2023 11:38:55 -0400
| Subject: Re: [PATCH V5, 1/2] PR target/105325: Rewrite genfusion.pl's
gen_ld_
Ping https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563496.html
| Date: Thu, 14 Jan 2021 11:59:19 -0500
| Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.
| Message-ID: <20210114165919.ga1...@ibm-toto.the-meissners.org>
As I've said in the past, this is the most important
I posted this patch on January 14th, 2021:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563498.html
| Date: Thu, 14 Jan 2021 12:09:36 -0500
| Subject: [PATCH] PowerPC: Add float128/Decimal conversions.
| Message-ID: <20210114170936.ga3...@ibm-toto.the-meissners.org>
You had a question a
On Wed, Jan 27, 2021 at 01:06:46PM -0600, will schmidt wrote:
> On Thu, 2021-01-14 at 11:59 -0500, Michael Meissner via Gcc-patches wrote:
> > From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001
> > From: Michael Meissner
> > Date: Wed, 13 Jan 2021 21:47
[PATCH, revised] PowerPC: Add float128/Decimal conversions.
This patch revises the patch on January 14th. The only change in this patch
compared to the previous patch is to change the format string for converting
IEEE 128-bit to string. This allows the c-c++-common/dfp/convert-bfp-6.c test
now p
>From 02b04aed77130f2ec9156d2f7ff89d4cc6b5a78b Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Thu, 21 Jan 2021 12:58:56 -0500
Subject: [PATCH, revised] PowerPC: Add float128/Decimal conversions.
[PATCH, revised] PowerPC: Add float128/Decimal conversions.
Unfortunately, the revision I just
On Wed, Jan 27, 2021 at 07:43:56PM -0600, Segher Boessenkool wrote:
> On Wed, Jan 27, 2021 at 01:06:46PM -0600, will schmidt wrote:
> > On Thu, 2021-01-14 at 11:59 -0500, Michael Meissner via Gcc-patches wrote:
> > > November 19th, 2020:
> > > Message-ID: <202
at 01:06:46PM -0600, will schmidt wrote:
> > > On Thu, 2021-01-14 at 11:59 -0500, Michael Meissner via Gcc-patches wrote:
> > > > November 19th, 2020:
> > > > Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>
> > >
> > > Subje
After testing the patch I submitted on November 17th that was approved to make
sure it still works, I commited the patch to the master branch. Sorry about
the intermediate rewrites.
[PATCH] Map long double built-ins correctly with IEEE 128-bit long double.
The PowerPC has two different 128-bit l
On Wed, Jan 27, 2021 at 09:11:49PM -0600, Segher Boessenkool wrote:
> On Tue, Jan 26, 2021 at 06:43:06PM -0500, Michael Meissner wrote:
> > I posted this patch on January 14th, 2021:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563498.html
> >
> > | Date: Thu, 14 Jan 2021 12:09:36 -0
On Thu, Jan 28, 2021 at 12:59:18PM -0600, Segher Boessenkool wrote:
> On Thu, Jan 28, 2021 at 01:10:39PM -0500, Michael Meissner wrote:
> > > The whole thread is at
> > > https://patchwork.ozlabs.org/project/gcc/patch/2020112524.ga...@ibm-toto.the-meissners.org/
> > > .
> > >
> > > I approve
[PATCH] Add conversions between _Float128 and Decimal.
This patch implements conversions between _Float128 and the 3 Decimal
floating types. It does by extendending the dfp-bit conversions to add a
new binary floating point type (KF), and doing the conversions in the same
mannor as the other bina
I rebusmitted the patch after verifying it still builds and works with the
current branch as:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564486.html
| Subject: [PATCH] Add conversions between _Float128 and Decimal.
| Message-ID: <20210129024208.ga25...@ibm-toto.the-meissners.org>
--
PR target/98870: Fix IEEE 128-bit fortran test
This test started failing when I changed the mapping of IEEE 128-bit long
double built-in functions on 2021-01-28. This patch fixes the test so it
uses the correct name.
I have tested this patch and the test now passes. Can I check it into the
mast
On Fri, Jan 29, 2021 at 03:45:49PM -0600, will schmidt wrote:
> On Thu, 2021-01-28 at 21:42 -0500, Michael Meissner via Gcc-patches wrote:
> > [PATCH] Add conversions between _Float128 and Decimal.
> >
>
> Hi,
> Just a couple cosmetic nits in the description. The ch
>From 4ceff15935a16da9ec5833279807855a8afc47cd Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Mon, 1 Feb 2021 22:19:57 -0500
Subject: [PATCH] Make asm not contain prefixed addresses.
In PR target/98519, the assembler does not like asm memory references that are
prefixed. We can't automati
Ping patch. This really needs to go in to allow switching the long double type
to IEEE 128-bit.
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564486.html
| Subject: [PATCH] Add conversions between _Float128 and Decimal.
| Message-ID: <20210129024208.ga25...@ibm-toto.the-meissners.org>
-
[PATCH V2] Add conversions between _Float128 and Decimal.
This patch implements conversions between _Float128 and the 3 Decimal floating
types. It does this by extendending the dfp-bit conversions to add a new
binary floating point type (KF), and doing the conversions in the same manner
as the ot
Ping patch
| Subject: [PATCH, V2] Add conversions between _Float128 and Decimal.
| Message-ID: <20210209073505.ga11...@ibm-toto.the-meissners.org>
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565009.html
I was asked to resubmit the patch with the copyright dates fixed, and Will's
comme
Ping patch
| Subject: [PATCH, V2] Add conversions between _Float128 and Decimal.
| Message-ID: <20210209073505.ga11...@ibm-toto.the-meissners.org>
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565009.html
I was asked to resubmit the patch with the copyright dates fixed, and Will's
comme
PR 99133, Mark xxspltiw, xxspltidp, and xxsplti32x as being prefixed
I noticed that the power10 xxspltiw, xxspltidp, and xxsplti32dx
instructions are not flagged as prefixed instructions, which means the
instruction length is not set to 12 bytes. This patch sets these
instructions to be prefixed.
On Wed, Feb 17, 2021 at 06:09:39PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Feb 17, 2021 at 12:17:30PM -0500, Michael Meissner wrote:
> > I noticed that the power10 xxspltiw, xxspltidp, and xxsplti32dx
> > instructions are not flagged as prefixed instructions, which means the
> > instruc
On Sat, Feb 20, 2021 at 06:33:12PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Feb 09, 2021 at 02:35:05AM -0500, Michael Meissner wrote:
> > This patch implements conversions between _Float128 and the 3 Decimal
> > floating
> > types. It does this by extendending the dfp-bit conversions t
As I mentioned in the patch for adding _Float128 <-> Decimal conversions, there
are two test cases that fail if you configure the compiler to use IEEE 128-bit
long double or 64-bit long double. That is because these tests are explicitly
testing that the long double is a pair of doubles (i.e. IBM 1
On Fri, Jan 15, 2021 at 06:16:43PM +, Joseph Myers wrote:
> On Thu, 14 Jan 2021, Michael Meissner via Gcc-patches wrote:
>
> > +return [check_runtime_nocache ppc_long_double_ovveride_ibm128 {
>
> > +return [check_runtime_nocache ppc_long_double_ovveride_ieee128
[PATCH 1/3] Add long double target-supports on PowerPC.
This patch add several more selections to target-supports.exp:
* 3 selections for the current long double format;
* 3 selections if we can change the long double format to a particular
value.
* 3 functions to return
[PATCH 2/3] Force long double to be IBM 128-bit on PowerPC test, PR
target/70117.
This patch fixes the pr70117 test to use IBM 128-bit long double.
I have run tests on a little endian power9 system with 3 compilers. There
were no regressions with these patches, and the two tests in the followin
[PATCH 3/3] Force IBM long double for conversion test on PowerPC.
The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
the IBM 128-bit extended double format. In particular, some of the tests
expect an infinity to be created if decimal values that are converted that are
On Wed, Feb 24, 2021 at 11:12:54PM +, Joseph Myers wrote:
> This change appears to have broken builds for powerpc in a configuration
> that bootstraps a cross toolchain starting with a GCC build with no libc
> available.
>
> Specifically, such a bootstrap build uses --disable-decimal-float a
Honor --disable-decimal-float in building _Float128 support.
Joseph Myers reported that my previous patch to add conversions between
_Float128 and the Decimal types was still being built even if GCC was
configured with the --disable-decimal-float option. This patch fixes that by
only building the
On Fri, Feb 26, 2021 at 04:36:20PM -0600, Segher Boessenkool wrote:
> On Fri, Feb 26, 2021 at 01:33:41AM -0500, Michael Meissner wrote:
> > Honor --disable-decimal-float in building _Float128 support.
> >
> > Joseph Myers reported that my previous patch to add conversions between
> > _Float128 and
I have broken the patches I submitted on Friday February 26th into 3 patches.
These patches allow us to build the libgcc library on PowerPC for VSX systems
and optionally enable/disable the Decimal support. If Decimal support is
disabled, then the Float128 <-> Decimal conversions are not built.
I
[PATCH 1/3 V2] Fix __sprintfkf prototype in libgcc.
The prototype of __sprintfkf in _sprintfkf.h did not match the function in
_sprintfkf.c. This patch fixes the prototype. I also included the
_sprintfkf.h file in _sprintfkf.c to make sure the prototype is correct and to
eliminate a warning abou
[PATCH 2/3 V2] Do not include stdio.h in libgcc's Decimal/Float128 conversions.
The _sprintfkf.c file was including stdio.h to get the definition of sprintf.
This patch modifies this so that stdio.h is not included in order to support
freestanding cross compilers that might not provide stdio.h.
I
[PATCH 3/3 V2] Do not build Decimal/Float128 conversions if decimal is disabled.
This patch suppresses building the Decimal <-> Float128 conversions if the user
used --disable-decimal-float when configuring GCC.
I have done bootstraps on a little endian power9 system with each of the long
double
On Mon, Mar 01, 2021 at 05:15:44PM -0600, Segher Boessenkool wrote:
> On Mon, Mar 01, 2021 at 12:18:52PM -0500, Michael Meissner wrote:
> > The _sprintfkf.c file was including stdio.h to get the definition of
> > sprintf.
>
> (declaration of)
>
> > This patch modifies this so that stdio.h is not
On Tue, Mar 02, 2021 at 03:53:06PM -0600, Segher Boessenkool wrote:
> If you want to make decimal and/or QP float work only on 64-bit LE Linux
> you should say so. And in that case, that is certainly not acceptable
> if it doesn't "sorry" at configure time already.
Well in general the only suppor
On Wed, Mar 03, 2021 at 11:33:52PM +, Joseph Myers wrote:
> On Wed, 3 Mar 2021, Michael Meissner via Gcc-patches wrote:
>
> > As we have discussed many times, on 32-bit BE, you cannot use hardware
> > _Float128 support on power9/power10 because there is no TImode in 3
[PATCH V3] Require GLIBC 2.32 for Decimal/_Float128 conversions.
In the patch that I applied on March 2nd, I had code to provide support for
Decimal/_Float128 conversions if the user did not use at least GLIBC 2.32. It
did this by using __ibm128 as an intermediate type. The trouble is __ibm128
c
[PATCH 2/2 V3] Do not build Decimal/Float128 conversions if
--disable-decimal-float.
This patch disables building the Decimal/_Float128 conversion functions if the
user configured the compiler with the --disable-decimal-float option.
This is a much simpler patch to disable building the Decimal/F
On Wed, Aug 04, 2021 at 02:14:07PM -0600, Sandra Loosemore wrote:
> I was trying last week to run my not-yet-committed TS29113 testsuite
> on a powerpc64le-linux-gnu target and ran into some problems with
> the kind constants c_float128 and c_float128_complex from the
> ISO_C_BINDING module; per th
On Thu, Aug 05, 2021 at 12:19:37PM -0600, Sandra Loosemore wrote:
> On 8/5/21 11:33 AM, Michael Meissner wrote:
> >At the moment, we only fully support C and C++ when changing the long double
> >format (between IEEE 128-bit, IBM 128-bit, and 64-bit) when the compiler is
> >invoked (and assuming you
[PATCH] Fix typo in fold-vec-load-builtin_vec_xl-* tests.
When I checked in the fix for running tests on power10 systems with
power10 code generation, I had a typo in the
fold-vec-load-builtin_vec_xl-* tests, swapping 'x' and 'v' in the p?lxv
pattern.
I checked this patch on a little endian power
On Wed, Aug 11, 2021 at 05:55:39AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
> > OK. I used your wording verbatim for the first one. For the second
> > one, I'm still pretty confused as I think it is at least theoretically
> >
On Sun, Aug 08, 2021 at 03:21:02PM -0500, Segher Boessenkool wrote:
> On Thu, Aug 05, 2021 at 10:44:36PM -0400, Michael Meissner wrote:
> > * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c: Fix
> > typo in regular expression.
> > * gcc.target/powerpc/fold-vec-load-builtin_vec_xl
Fix tests that require IBM 128-bit long double
I posted an earlier version of this patch on July 7th, and Segher had some
comments about it on July 14th. This is a revised version of the patch
* My patch: Message-ID: <20210707195837.ga28...@ibm-toto.the-meissners.org>
* Seger's reply: Message-
Fix xxeval predicates (PR 99921).
I originally posted this patch in May and in June. I'm reposting it now.
I noticed that the xxeval built-in function used the altivec_register_operand
predicate. Since it takes vsx registers, this might force the register
allocate to issue a move when it could
Move xx* builtins to vsx.md.
I originally posted this patch in May. It needed a slight tune up as the
souces have changed, so I'm reposting it now.
I noticed that the xx built-in functions (xxspltiw, xxspltidp, xxsplti32dx,
xxeval, xxblend, and xxpermx) were all defined in altivec.md. However,
On Fri, Aug 13, 2021 at 04:33:26PM -0400, David Edelsohn wrote:
> There is a song from Sesame Street: "Which of these is not like the
> others?" altivec.md seems like an outlier. crypto.md and vsx.md also
> seem unusual.
>
> We have
>
> register_operand
> gpc_reg_operand
> altivec_register_oper
On Wed, Aug 18, 2021 at 06:11:03PM -0500, Segher Boessenkool wrote:
> On Wed, Aug 18, 2021 at 04:42:42PM -0400, David Edelsohn wrote:
> > I wanted to give Segher a chance to comment on the structure.
>
> I think the current vector.md / altivec.md / vsx.md / rs6000.md
> division is artificial at be
Make xxsplti*, xpermx, xxeval be vecperm type.
I noticed that the built-functions for xxspltiw, xxspltidp, xxsplti32dx,
xxpermx, and xxeval all used the 'vecsimple' type. These instructions are
permute instructions (3 cycle latency) and should use 'vecperm' instead.
While I was at it, I changed
On Wed, Aug 25, 2021 at 12:44:16PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, Aug 25, 2021 at 12:37:14PM -0400, Michael Meissner wrote:
> > I noticed that the built-functions for xxspltiw, xxspltidp, xxsplti32dx,
> > xxpermx, and xxeval all used the 'vecsimple' type. These instructio
Generate XXSPLTIDP on power10.
This patch implements XXSPLTIDP support for SF and DF scalar constants and V2DF
vector constants. The XXSPLTIDP instruction is given a 32-bit immediate that
is converted to a vector of two DFmode constants. The immediate is in SFmode
format, so only constants that
>From 327273dfeec5c000f3c33ca7b88ee0097fd33586 Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Wed, 25 Aug 2021 00:31:35 -0400
Subject: [PATCH] Fix float128-call.c test for power8 IEEE 128 and power10.
I built a compiler on a little endian power8 system where the default long
double was IEE
On Wed, Aug 25, 2021 at 05:29:22PM -0500, Segher Boessenkool wrote:
> On Wed, Aug 25, 2021 at 02:22:06PM -0400, Michael Meissner wrote:
> > On Wed, Aug 25, 2021 at 12:44:16PM -0500, Segher Boessenkool wrote:
> > > Out of interest, did you notice any scheduling differences with this?
> >
> > I don'
On Thu, Aug 26, 2021 at 02:17:57PM -0500, will schmidt wrote:
> On Wed, 2021-08-25 at 15:46 -0400, Michael Meissner wrote:
> > Generate XXSPLTIDP on power10.
> >
> > I have added a temporary switch (-mxxspltidp) to control whether or not the
> > XXSPLTIDP instruction is generated.
>
> How tempora
On Fri, Aug 13, 2021 at 05:22:47PM +, Joseph Myers wrote:
> On Fri, 13 Aug 2021, Andreas Schwab wrote:
>
> > On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote:
> > How can it happen that __LONG_DOUBLE_IEEE128__ is not defined? This
> > file is always compiled with -mfloat128 and this l
On Thu, Aug 26, 2021 at 05:28:42PM -0400, Michael Meissner wrote:
> I have patches for adding XXSPLTI32DX, but so far, I'm not sure whether it is
> a
> win or not. This has the xxsplti32dx_operand predicate and the
> xxsplti32dx_constant_p internal function and a separate constraint ("eD") for
>
On Fri, Aug 27, 2021 at 11:41:06AM -0500, Bill Schmidt wrote:
> This amuses me, and I want to keep it this way. :-)
> > void store (TYPE a, TYPE *p) { *p = a; }
> > -/* { dg-final { scan-assembler {\mlxvd2x 34\M} {target be} } } */
> > -/* { dg-final { scan-assembler {\mstxvd2x 34\M} {target be}
On Fri, Aug 27, 2021 at 12:29:42PM -0500, Segher Boessenkool wrote:
> On Wed, Aug 25, 2021 at 06:09:44PM -0400, Michael Meissner wrote:
> > I built a compiler on a little endian power8 system where the default long
> > double was IEEE 128-bit instead of IBM 128-bit. I discovered that on
> > power8
Ping patch.
| Date: Wed, 25 Aug 2021 15:46:43 -0400
| Subject: [PATCH] Generate XXSPLTIDP on power10.
| Message-ID:
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Here is the patch that I applied:
>From 1a2e0742e3e3c45f75d0ce31c45a7778c8d1f45e Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Fri, 11 Sep 2020 16:57:13 -0400
Subject: [PATCH] PowerPC: rename some functions.
gcc/
2020-09-11 Michael Meissner
* config/rs6000/rs6000.c (rs6000_ma
1 - 100 of 632 matches
Mail list logo
