On Sat, Oct 31, 2020 at 11:39:23PM +1030, Alan Modra wrote:
> Hi Mike,
> On Wed, Oct 28, 2020 at 08:42:04PM -0400, Michael Meissner via Gcc-patches
> wrote:
> > PowerPC: PR libgcc/97543, fix 64-bit long double issues
> >
> > There are two issues in PR libgcc/97543
On Fri, Oct 30, 2020 at 06:39:16PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 30, 2020 at 06:50:30PM -0400, Michael Meissner wrote:
> > On Fri, Oct 30, 2020 at 03:54:06PM -0500, Segher Boessenkool wrote:
> > > But, time will fix all problems here. So, okay for trunk. Thanks!
> >
> > Note, I
On Fri, Oct 30, 2020 at 03:54:06PM -0500, Segher Boessenkool wrote:
> But, time will fix all problems here. So, okay for trunk. Thanks!
Note, I discovered the ABI is not set to ELFv2 at the time the test is done, so
I removed that part of the test.
This is the patch I committed:
>From
On Fri, Oct 30, 2020 at 01:52:13PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 30, 2020 at 01:21:34PM -0400, Michael Meissner wrote:
> > David reminded me that not all targets support GLIBC. This patch should
> > fix my
> > previous committed patch not to use TARGET_GLIBC_MAJOR or
PowerPC: Don't assume all targets have GLIBC.
David reminded me that not all targets support GLIBC. This patch should fix my
previous committed patch not to use TARGET_GLIBC_MAJOR or TARGET_GLIBC_MINOR
unless they are defined.
I have done a bootstrap on a little endian power9 system and it was
On Thu, Oct 29, 2020 at 02:18:58PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 29, 2020 at 01:03:25PM -0400, Michael Meissner wrote:
> > On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote:
> > > > +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> > >
> > > Use
On Thu, Oct 29, 2020 at 03:08:07PM -0500, Segher Boessenkool wrote:
> It isn't set anywhere else.
>
> Mike, the patch is okay for trunk with that line restored. Thanks!
> (And thanks for spotting the problem Will!)
It is set since the variable is a static. The whole point is to only raise the
On Thu, Oct 29, 2020 at 01:32:53PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 29, 2020 at 12:50:10PM -0400, Michael Meissner wrote:
> > On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote:
> > > On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote:
> > > > This patch
On Mon, Oct 26, 2020 at 05:48:48PM -0500, will schmidt wrote:
> On Thu, 2020-10-22 at 18:15 -0400, Michael Meissner via Gcc-patches wrote:
> > PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.
> >
> > This is a new patch. It turns off the warning about switching
On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Oct 22, 2020 at 06:11:35PM -0400, Michael Meissner wrote:
> > This patch attempts to make the error messages for intermixing IEEE 128-bit
> > floating point with IBM 128-bit extended double types to be clearer
On Tue, Oct 27, 2020 at 09:30:03AM -0500, will schmidt wrote:
> On Thu, 2020-10-22 at 18:10 -0400, Michael Meissner via Gcc-patches wrote:
> > PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
> >
> > I have split all of these patches into separate pat
On Wed, Oct 28, 2020 at 04:58:46PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Thu, Oct 22, 2020 at 06:10:37PM -0400, Michael Meissner wrote:
> > PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
>
> This title makes no sense, and thankfully is not what the patch does
On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote:
> > This patch adds long double variants of the power10 __float128 built-in
> > functions. This is needed when long double uses IEEE 128-bit because
> >
On Tue, Oct 27, 2020 at 09:38:20AM -0500, will schmidt wrote:
> > @@ -2420,6 +2423,8 @@ BU_P9V_64BIT_VSX_2 (VSIEDPF, "scalar_insert_exp_dp",
> > CONST, xsiexpdpf)
> >
> > BU_FLOAT128_HW_VSX_2 (VSIEQP, "scalar_insert_exp_q", CONST,
> > xsiexpqp_kf)
> > BU_FLOAT128_HW_VSX_2 (VSIEQPF,
On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 22, 2020 at 06:06:03PM -0400, Michael Meissner wrote:
> > This patch adds the various decimal to/from IEEE 128-bit conversions. I
> > had to make some changes to the infrastructure, since that infrastructure
> >
Please withdraw from consideration the patch that turned on -mno-gnu-attribute
for just the ibm-ldouble.o module in favor of the patch for PR libgcc/97543
that I just posted:
PR libgcc/97543 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557413.html
Withdrawn patch:
PowerPC: PR libgcc/97543, fix 64-bit long double issues
There are two issues in PR libgcc/97543 which shows up if you build a GCC
compiler with long double defaulting to 64-bit instead of 128-bit with IBM
extended double:
1) The first issue was the t-linux file forced the entire libgcc
PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.
This is a new patch. It turns off the warning about switching the long double
type via compile line if the GLIBC is 2.32 or newer. It only does this if the
languages are C or C++, since those language libraries support switching the
PowerPC: Use __float128 instead of __ieee128 in tests.
I have split all of these patches into separate patches to hopefully get them
into the tree.
Two of the tests used the __ieee128 keyword instead of __float128. This
patch changes those cases to use the official keyword.
I have tested this
PowerPC: Update __float128 and __ibm128 error messages.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch attempts to make the error messages for intermixing IEEE 128-bit
floating point with IBM 128-bit extended double types to be clearer if
PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch adds long double variants of the power10 __float128 built-in
functions. This is needed when long double uses IEEE
PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch changes the __ibm128 emulator to use __builtin_pack_ieee128
instead of __builtin_pack_longdouble if long double is IEEE
PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
I have split all of these patches into separate patches to hopefully get them
into the tree.
If we map nanq to nanf128 when long double is IEEE, it seems to lose the
special signaling vs. non-signaling NAN support.
PowerPC: Update long double IEEE 128-bit tests.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch fixes 3 tests in the testsuite that fail if long double is set
to IEEE 128-bit.
I have tested this patch with bootstrap builds on a little
PowerPC: Add __float128 conversions to/from Decimal.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch adds the various decimal to/from IEEE 128-bit conversions. I
had to make some changes to the infrastructure, since that infrastructure
PowerPC: Add -mno-gnu-attributes to ibm-ldouble.o.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch is split off from the patch adding __float128 <-> Decimal
conversions. This patch is needed to prevent the linker from issuing a
warning
PowerPC: Map IEEE 128-bit long double built-in functions
This patch is revised from the first and second versions of the patch posted.
It now uses the names that are not in the user's namespace (i.e. __sinieee128
instead of sinf128) that Joseph Myers suggested.
In addition, I added the changes
On Fri, Oct 16, 2020 at 03:30:56PM -0500, Segher Boessenkool wrote:
> > + if (len >= printf_len
> > + && strcmp (name + len - printf_len, "printf") == 0)
>
> Thew first test is unnecessary.
Actually no, it is necessary. If you are looking at a builtin function with 4
or fewer
On Fri, Oct 16, 2020 at 03:30:56PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 09, 2020 at 12:35:44AM -0400, Michael Meissner wrote:
> > This patch is revised from the first version of the patch posted.
>
> In the future, please send a NEW series, in a NEW thread, when you have
> a new series.
On Fri, Oct 16, 2020 at 02:14:04PM -0500, Segher Boessenkool wrote:
> On Thu, Sep 24, 2020 at 04:20:36PM -0400, Michael Meissner wrote:
> > This series of 9 patches is an attempt to gather together all of the patches
> > that are needed to be able to configure and build a little endian 64-bit
> >
Ping (#2) the following 9 patches to add support for building a GCC toolchain
where the default long double is IEEE 128-bit floating point instead of the IBM
extended double floating point.
The first patch was revised with input from Joesph Myers. I will list that
patch in this list. Most of
Ping the following 9 patches to add support for building a GCC toolchain where
the default long double is IEEE 128-bit floating point instead of the IBM
extended double floating point.
The first patch was revised with input from Joesph Myers. I will list that
patch in this list. Most of these
Ping the following two patches to add IEEE 128-bit minimum, maximu, and
conditional move support:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554460.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554461.html
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street,
PowerPC: Map long double built-in functions if IEEE 128-bit long double.
This patch is revised from the first version of the patch posted. It uses the
names that are not in the user's namespace (i.e. __sinieee128 instead of
sinf128) that Joseph Myers suggested.
This patch goes through the
On Thu, Oct 01, 2020 at 11:05:04PM +, Joseph Myers wrote:
> On Thu, 24 Sep 2020, Michael Meissner via Gcc-patches wrote:
>
> > To map the math functions, typically this patch changes l to
> > f128.
> > However there are some exceptions that are handled with this patc
On Thu, Sep 24, 2020 at 10:24:52AM +0200, Florian Weimer wrote:
> * Michael Meissner via Gcc-patches:
>
> > These patches are my latest versions of the patches to add IEEE 128-bit min,
> > max, and conditional move to GCC. They correspond to the earlier patches #3
> > a
PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
This patch changes the __ibm128 emulator to use __builtin_pack_ieee128
instead of __builtin_pack_longdouble if long double is IEEE 128-bit, and
we need to use the __ibm128 type.
libgcc/
2020-09-23 Michael Meissner
*
>From e4114c9c13067b356f9ab5c5bb4c6a928771aef8 Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Wed, 23 Sep 2020 17:12:56 -0400
Subject: [PATCH 8/9] PowerPC: Change tests to use __float128 instead of
__ieee128.
Two of the tests used the __ieee128 keyword instead of __float128. This
patch
PowerPC: Update IEEE 128-bit built-in functions to work if long double is IEEE
128-bit.
This patch adds long double variants of the power10 __float128 built-in
functions. This is needed because __float128 uses TFmode in this case
instead of KFmode.
gcc/
2020-09-23 Michael Meissner
PowerPC: If long double is IEEE 128-bit, map q built-ins to *l instead of *f128.
If we map nanq to nanf128 when long double is IEEE, it seems to lose the
special signaling vs. non-signaling NAN support. This patch maps the functions
to the long double version if long double is IEEE 128-bit.
PowerPC: Update tests to run if long double is IEEE 128-bit.
gcc/testsuite/
2020-09-23 Michael Meissner
* c-c++-common/dfp/convert-bfp-11.c: If long double is IEEE
128-bit, skip the test.
* gcc.dg/nextafter-2.c: On PowerPC, if long double is IEEE
128-bit,
PowerPC: Add IEEE 128-bit <-> Decimal conversions.
This patch adds the basic support for converting between IEEE 128-bit floating
point and Decimal types.
libgcc/
2020-09-23 Michael Meissner
* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
PowerPC: Update IEEE <-> IBM 128-bit floating point conversions.
This patch changes the code for doing conversions between IEEE 128-bit floating
point and IBM 128-bit extended double floating point. It moves the conversion
functions to a separate file. It uses explicit __ibm128 instead of long
PowerPC: Update __float128 and __ibm128 error messages.
This patch attempts to make the error messages for intermixing IEEE 128-bit
floating point with IBM 128-bit extended double types to be clearer if the long
double type uses the IEEE 128-bit format.
gcc/
2020-09-23 Michael Meissner
PowerPC: Map long double built-in functions if IEEE 128-bit long double.
This patch goes through the built-in functions and changes the name that is
used to the name used for __float128 and _Float128 support in glibc if the
PowerPC long double type is IEEE 128-bit instead of IBM extended double.
This series of 9 patches is an attempt to gather together all of the patches
that are needed to be able to configure and build a little endian 64-bit
PowerPC Linux GCC compiler where the defualt long double format uses the IEEE
128-bit representation.
I have created an IBM vendor branch that
Power10: Add IEEE 128-bit fp conditional move.
This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max. Unlike the previous patch, I
decided to keep two separate patterns for fpmask before splitting (one pattern
for normal
Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.
This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions. The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.
Rather than trying to
These patches are my latest versions of the patches to add IEEE 128-bit min,
max, and conditional move to GCC. They correspond to the earlier patches #3
and #4 (patches #1 and #2 have been installed).
The first patch just adds support for the xsmincqp and xsmaxcqp instructions.
Due to the NaN
In case this patch has gotten over-looked, the three patches in the set plus
the explanation are the rewrite of the PCREL_OPT patches. It has been
rewritten to use the data flow machinery as well as validate_change and
apply_change_group from the last patch.
The PCREL_OPT patches can go anywhere
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
I forgot to add Bill Schmidt's name to the ChangeLog entry. He helped with the
initial conversion to use the DF framework. I will add his name in my copy of
the patch.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone:
power10: Add tests for PCREL_OPT.
This patch add the PCREL_OPT tests for the previous two patches.
I have built compilers with and without these set of 3 patches doing a
bootstrap build and make check. There were no regressions, and the new tests
passed. Can I check these patches into the
power10: Add PCREL_OPT store support.
This patch adds support for optimizing power10 stores to an external variable to
eliminate loading the address of the variable, and then doing a subsequent load
using that address.
The previous patch added the support for optimizing power10 loads from an
power10: Add PCREL_OPT load support.
This patch adds support for optimizing power10 loads of an external variable to
eliminate loading the address of the variable, and then doing a subsequent load
using that address.
The next patch will add the support for optimizing power10 stores to an
The ELF-v2 ISA 3.1 support for Power10 has relocations to optimize cases where
the code is references an external variable in only one location. This patch
is similar to the optimizations that the linker already does to optimize TOC
accesses.
This patch is a revision of the patches last
On Thu, Aug 20, 2020 at 09:09:40PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 18, 2020 at 02:34:01AM -0400, Michael Meissner wrote:
> > +// Maximum number of insns to scan between the load address and the load
> > that
>
> Please don't mix /* and // comments. Just stick to /*
On Thu, Aug 27, 2020 at 03:47:19PM -0500, will schmidt wrote:
> > (Fm): New mode attribute for floating point scalars.
>
> Mixed feels on mixed case, but I defer. :-)
It is similar to other mode attributes (Ff, Fv) used for setting constraints
based on the mode.
--
Michael Meissner, IBM
PowerPC: Add power10 xscmp{eq,gt,ge}qp support.
This patch adds the conditional move support. In adding the conditional move
support, the optimizers will be able to convert things like:
a = (b > c) ? b : c;
into the instructions. This patch merges together the scalar SF/DF conditional
PowerPC: Add power10 xsmaxcqp/xsmincqp support.
This patch adds support for the ISA 3.1 (power10) IEEE 128-bit "C" minimum and
maximum functions. Because of the NaN differences, the built-in functions will
only generate these instructions if -ffast-math is used until the conditional
move support
PowerPC: Rename functions for min, max, cmove.
This patch renames the functions that generate the ISA 3.0 C minimum, C
maximum, and conditional move instructions to use a better name than just using
a _p9 suffix. Because the functions can fail, the names use "maybe_emit"
instead of "generate_"
PowerPC: Change cmove function return to bool.
In doing the other work for adding ISA 3.1 128-bit minimum, maximum, and
conditional move support, I noticed the two functions that process conditional
moves return 'int' instead of 'bool'. This patch changes these functions to
return 'bool'.
I
The following patches are a rewrite of the previous set of patches to add
support for the power10 IEEE 128-bit C minimum, C maximum, and compare/set mask
instructions that are similar to the instructions added in power9.
There are 4 patches in this series.
The first patch is a cosmetic patch.
I forgot to mention that comparing the three tests of placement of the
PCREL_OPT pass:
Having the pass after sched2 generated the same number of PCREL_OPT relocations
as having the pass immediately after reload.
But having the pass just before sched2 resulted in some more PCREL_OPT
relocations.
On Sat, Aug 22, 2020 at 07:05:51PM -0500, Bill Schmidt wrote:
> What is necessary in order to allow this optimization to occur
> earlier is to make this hidden dependency explicit. When the
> relocation is inserted, we have to change the "pld" instruction to
> have a specific clobber of (in this
On Thu, Aug 20, 2020 at 06:33:29PM -0500, Segher Boessenkool wrote:
> > These patches allow the load of the address to not be physically adjacent to
> > the actual load or store, which should allow for better code.
>
> Why is that? That is not what it does anyway? /confused
It does allow that.
[PATCH 3/3] Power10: Add tests for PCREL_OPT support.
These are the tests for the PCREL_OPT support.
gcc/testsuite/
2020-08-18 Michael Meissner
* gcc.target/powerpc/pcrel-opt-inc-di.c: New PCREL_OPT test.
* gcc.target/powerpc/pcrel-opt-ld-df.c: New PCREL_OPT test.
*
[PATCH 2/3] Power10: Add PCREL_OPT store support.
This patch adds support for optimizing power10 stores to an external variable
to eliminate loading the address of the variable, and then doing a subsequent
store using that address.
I have built compilers with and without these set of 3 patches
[PATCH 1/3] Power10: Add PCREL_OPT load support.
This patch adds support for optimizing power10 loads of an external variable to
eliminate loading the address of the variable, and then doing a subsequent load
using that address.
I have built compilers with and without these set of 3 patches
The ELF-v2 ISA 3.1 support for Power10 has relocations to optimize cases where
the code is references an external variable in only one location. This patch
is similar to the optimizations that the linker already does to optimize TOC
accesses.
I will be submitting 3 patches as follow-ups to this
On Tue, Aug 11, 2020 at 08:01:50PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 11, 2020 at 12:23:07PM -0400, Michael Meissner wrote:
> > + /* See if we can use the ISA 3.1 min/max/compare instructions for IEEE
> > + 128-bit floating point. At present, don't worry about doing
> >
PowerPC: Add power10 IEEE 128-bit min/max/cmove.
This patch adds support for the new ISA 3.1 (power10) xscmp{eq,gt,ge}qp,
xsmincqp, and xsmaxcqp instructions for IEEE 128-bit conditional move, minimum,
and maximum.
gcc/
2020-08-07 Michael Meissner
* config/rs6000/rs6000.c
PowerPC: Rename min/max/cmove functions.
This patch renames some of the functions in rs6000.c that are used to generate
floating point scalar minimum, maximum, and conditional move sequences to use a
more generic name then _p9.
gcc/
2020-08-07 Michael Meissner
*
These two patches are a reworking of similar patches that I submitted in July.
The change in these patches are to rename the functions that generate the
minimum, maximum, and compare IEEE 128-bit to produce a mask to use better
names, and to rework the comments. In addition, I have changed the
Power10: Add BRH, BRW, BRD support.
The power10 processor adds 3 new instructions (BRH, BRW, BRD) that byte swaps
half-words, words, and double-words within a GPR register. This patch adds
support for these instructions. I have applied the suggestions from the
previous times I have submitted
Backport power10 prefix stack protect test.
This test makes sure whether large stack frames can be handled if the
-fstack-protector-stron option was used. This bug was noticed when we tried to
build GLIBC for the power10. This test has been on the master branch since
June, and not changes were
Backport power10 prefix no-update test.
This test insures that we do not try to generate an update format instruction
for prefixed load/store instructions. This test has been on the master branch
since June, and no changes were needed to backport it to GCC 10. Can I check
this patch into the
Backport Power10 PC-relative tests.
These tests whether the power10 PC-relative load/store instructions are
generated. These tests have been on the master branch since June. No changes
were needed to backport them to the GCC 10 branch. Can I check these into the
GCC 10 branch?
gcc/testsuite/
Backport Power10 prefix tests with large offsets.
These tests test whether a prefixed instruction is generated if the offset is
larger than the 16-bits used by the traditional instructions, but smaller than
the 34-bit limit of the prefixed instructions. These tests have been on the
master branch
Backport Power10 prefix test for DS/DQ.
This patch adds a test to make sure offsets that are not legal for non-prefixed
DS/DQ instructions are legal for a prefixed instruction. This test has been in
the master branch since June, and no changes were needed to backport it to GCC
10. Can I check
Backport Power10 paddi/pli tests
This backport patch adds test for the PADDI instruction (and the PLI variant)
to add or load up 34 bit constants. It has been in the master branch since
June, and no changes were needed for GCC 10. Can I check this into the GCC 10
branch?
gcc/testsuite/
The following 6 patches backport the tests on the master branch that were added
to test the new prefixed instructions being added to the Power10 processor.
These patches include changes made by David Edelsohn to make the patches work
on AIX. I have tested them on a GCC 10 compiler on a little
This patch fixes a PR that I noticed several years ago during power8
development. I noticed that the compiler would often create a two element
vector and store the vector.
Particularly for DImode on power8, this could involve two direct moves and a
XXPERMDI to glue the two parts together. On
This patch adds support for the IEEE 128-bit floating point minimum, maximum,
and compare instructions generating a mask. These instructions were added in
ISA 3.1 (i.e. power10).
Compared to the last time I submitted the patches, I changed from using
-mcpu=future to -mcpu=power10. Along with
This patch changes the name of two functions that were added to support power9
instructions, so that the name of these functions are no longer specific to
power9.
The next patch will add support for the power10 IEEE 128-bit minimum, maximum,
and conditional move instructions. This patch renames
The two patches that will be mailed as replies to this patch add support for
the IEEE 128-bit floating point minimum, maximum, and set mask based on
comparison instructions.
These patches were previous submitted as:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/546992.html
This patch adds support for the Power10 BRD, BRW, and BRH instructions that do
byte swapping on values in GPRs.
This patch is a revision of the byte swap patch proposed in:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/546990.html
I changed the DI swap function bswapdi2_brd instead of
On Mon, Jun 29, 2020 at 01:42:56PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 29, 2020 at 02:23:22PM -0400, Michael Meissner wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c
> > @@ -0,0 +1,13 @@
> > +/* { dg-do compile } */
> > +/* {
>From 212475e5757fe3335cba30c9c3eec1707ac0c271 Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Sat, 27 Jun 2020 00:40:48 -0500
Subject: [PATCH, committed] Add PowerPC tests for power10.
2020-06-27 Michael Meissner
* gcc.target/powerpc/prefix-add.c: New test.
*
On Thu, Jun 25, 2020 at 11:52:50AM -0500, Segher Boessenkool wrote:
> On Mon, Jun 01, 2020 at 03:53:37PM -0400, Michael Meissner wrote:
> > Add tests for -mcpu=future that test the generation of PADDI (and PLI which
> > becomes PADDI).
> >
> > 2020-06-01 Michael Meissner
> >
> > *
On Thu, Jun 25, 2020 at 12:09:41PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 04, 2020 at 01:03:51PM -0400, Michael Meissner wrote:
> > [PATCH 5/7, V2] PowerPC tests: Prefixed insn with large offsets
> >
> > Add tests to make sure for -mcpu=future that prefixed load/store
> >
On Thu, Jun 25, 2020 at 12:18:42PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 01, 2020 at 03:53:42PM -0400, Michael Meissner wrote:
> > Test that stack protection generates prefixed stack instructions if you are
> > using large stack frame for -mcpu=future.
> >
> > 2020-06-01
On Thu, Jun 25, 2020 at 11:52:50AM -0500, Segher Boessenkool wrote:
> On Mon, Jun 01, 2020 at 03:53:37PM -0400, Michael Meissner wrote:
> > Add tests for -mcpu=future that test the generation of PADDI (and PLI which
> > becomes PADDI).
> >
> > 2020-06-01 Michael Meissner
> >
> > *
On Thu, Jun 25, 2020 at 06:54:26PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 25, 2020 at 06:36:51PM -0500, Peter Bergner wrote:
> > rs6000: Add support for __builtin_cpu_is ("power10")
> >
> > Add support for __builtin_cpu_is ("power10"). Also add documentation for
> > the recently
This patch adds support for the two new HWCAP2 fields used by the
__builtin_cpu_supports function. It adds support in the target_clones
attribute for -mcpu=future.
The two new __builtin_cpu_supports tests are:
__builtin_cpu_supports ("isa_3_1")
__builtin_cpu_supports ("mma")
The
[PATCH 6/7, V2] PowerPC tests: Add PC-relative tests.
These tests make sure that PC-relative variant is generated for -mcpu=future on
systems that support PC-relative addressing. The only difference
is I reworded the comments, based on a suggestion by Will Schmidt.
2020-06-03 Michael Meissner
[PATCH 5/7, V2] PowerPC tests: Prefixed insn with large offsets
Add tests to make sure for -mcpu=future that prefixed load/store instructions
are generated if the offset is larger than 16 bits. The only difference
is I reworded the comments, based on a suggestion by Will Schmidt.
2020-06-04
On Mon, Jun 01, 2020 at 05:45:34PM -0500, will schmidt wrote:
> Similar/same comment as was made in Apr.I recommend something like
>
> "Test whether pc-relative prefixed instructions
> are generated for the _Decimal64 type."
Ok, I missed that comment in April.
--
Michael Meissner, IBM
This patch renames some functions that were added for power9 support that are
named '_p9' to be '_hw'. This is preparation for the next patch that wants to
extend these functions for -mcpu=power support.
2020-06-01 Michael Meissner
* config/rs6000/rs6000.c (rs6000_emit_hw_fp_minmax):
Add support for generating BRH/BRW/BRD when -mcpu=future is used.
gcc/
2020-06-01 Michael Meissner
* config/rs6000/rs6000.md (bswaphi2_reg): If -mcpu=future,
generate the BRH instruction.
(bswapsi2_reg): If -mcpu=future, generate the BRW instruction.
501 - 600 of 632 matches
Mail list logo
