On Thu, Aug 24, 2023 at 09:19:51PM -0500, Peter Bergner wrote:
> On 8/24/23 12:35 PM, Michael Meissner wrote:
> > On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
> >> gcc/
> >>PR target/110411
> >>* config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
> >>to
On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> When the user specifies PTImode as an attribute, it breaks. Created
> a tree node to handle PTImode types. PTImode attribute helps in
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
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
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 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
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
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,
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,
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,
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
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
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*)’:
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 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
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
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
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
On Tue, May 02, 2023 at 05:32:04PM -0500, Segher Boessenkool wrote:
> On Wed, Apr 26, 2023 at 12:18:36PM -0400, Michael Meissner wrote:
> > * gcc/config/rs6000/genfusion.pl (gen_ld_cmpi_p10): Improve generation
> > of the ld and lwa instructions which use the DS encoding instead of D.
> >
I posted a version of patch on March 21st, a second version on March 24th, and
the third version on March 28th.
The V4 patch just adds a new condition to the new test case. Previously, I was
using 'powerpc_prefixed_addr' to determine whether the GCC compiler would
automatically generate prefixed
Ping for patch 105325. I believe patch V3 answers the objections raised
earlier. Can I check this patch into master? Then can I apply this patch to
GCC 12 and 11 after appropriate delays?
| Date: Mon, 27 Mar 2023 23:19:55 -0400
| Subject: [PATCH, V3] PR target/105325, Make load/cmp fusion know
On Wed, Apr 12, 2023 at 01:31:46PM +0800, Jiufu Guo wrote:
> I understand that QP insns (e.g. xscmpexpqp) is valid if the system
> meets ISA3.0, no matter BE/LE, 32-bit/64-bit.
> I think option -mfloat128-hardware is designed for QP insns.
>
> While there is one issue, on BE machine, when
This is version 3 of the patch. This is essentially version 1 with the removal
of changes to altivec.md, and cleanup of the comments.
Version 2 generated the vmaddfp and vnmsubfp instructions if -Ofast was used,
and those changes are deleted in this patch.
The Altivec instructions vmaddfp and
This is version 2 of the patch. The first version was posted on April 6th.
In this version, I eliminated the changes to Altivec.md that added checks to
altivec_fmav4sf4 and altivec_vnmsubfp. After writing the code, I remembered
that VECTOR_UNIT_ALTIVEC_P that is used by those insns will not be
On Thu, Apr 06, 2023 at 03:37:59PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Apr 06, 2023 at 11:12:11AM -0400, Michael Meissner wrote:
> > The Altivec instructions fmaddfp and fnmsubfp have different rounding
> > behaviors
>
> Those are not existing instructions. You mean "vmaddfp"
The Altivec instructions fmaddfp and fnmsubfp have different rounding behaviors
than the VSX xvmaddsp and xvnmsubsp instructions. In particular, generating
these instructions seems to break Eigen.
GCC has generated the Altivec fmaddfp and fnmsubfp instructions on VSX systems
as an alternative to
Ping patch:
| Date: Mon, 27 Mar 2023 23:19:55 -0400
| From: Michael Meissner
| Subject: [PATCH, V3] PR target/105325, Make load/cmp fusion know about
prefixed loads
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On Mon, Mar 27, 2023 at 03:03:17PM +0800, Kewen.Lin wrote:
> ... instead I suggested moving these three lines to below else arm for CCUNS,
> since the arm for CC already has those variables redefined, so it's something
> like:
I did those changes in the 3rd version of the patch.
| Date: Mon, 27
I posted a version of patch on March 21st and a second version on March 24th.
This patch makes some code changes suggested in the genfusion.pl code from the
last 2 patch submissions. The fusion.md that is produced by genfusion.pl is
the same in all 3 versions.
I changed the genfusion.pl to match
On Thu, Mar 23, 2023 at 04:10:22PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> Thanks for fixing this, some minor comments are inlined below.
>
> on 2023/3/22 07:53, Michael Meissner wrote:
> > The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion
> > optimization generates illegal
I posted a version of patch on March 21st. This patch makes some code changes
suggested in the genfusion.pl code. The only change is in genfusion.pl. The
fusion.md that it makes is the same.
The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion
optimization generates illegal
The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion
optimization generates illegal assembler code.
Ultimately the code was dying because the fusion load + compare -1/0/1 patterns
did not handle the possibility that the load might be prefixed.
The main cause is the constraints for
On Mon, Mar 20, 2023 at 01:43:41PM -0400, Michael Meissner wrote:
> I think we will need backports for GCC 12. The issue exists in GCC 11, but I
> don't think that GCC 11 can really work on systems with IEEE long double,
> since
> a lot of the stuff to really finish up the support was not in GCC
On Fri, Mar 17, 2023 at 02:35:16PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Mar 09, 2023 at 08:40:36PM -0500, Michael Meissner wrote:
> > PR target/109067
> > * config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
> > (init_float128_ieee): Delete code to switch complex
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
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
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
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:
>
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.
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:
--
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
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
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
This patch adds support for a saturating subtract built-in function that may be
added to a future PowerPC processor. Note, if it is added, the name of the
built-in function may change before GCC 13 is released. If the name changes,
we will submit a patch changing the name.
I also added support
This patch adds support for new instructions that may be added to the PowerPC
architecture in the future to enhance the load and store vector with length
instructions.
The current instructions (lxvl, lxvll, stxvl, and stxvll) are inconvient to use
since the count for the number of bytes must be
This patch is a prelimianry patch to add the full 1,024 bit dense math register
(DMRs) for -mcpu=future. The MMA 512-bit accumulators map onto the top of the
DMR register.
This patch only adds the new 1,024 bit register support. It does not add
support for any instructions that need 1,024 bit
This patch changes the assembler instruction names for MMA instructions from
the original name used in power10 to the new name when used with the dense math
system. I.e. xvf64gerpp becomes dmxvf64gerpp. The assembler will emit the
same bits for either spelling.
The patches have been tested on
This patch changes the MMA instructions to use either FPR registers
(-mcpu=power10) or DMRs (-mcpu=future). In this patch, the existing MMA
instruction names are used.
A macro (__PPC_DMR__) is defined if the MMA instructions use the DMRs.
The patches have been tested on the following platforms.
The MMA subsystem added the notion of accumulator registers as an optional
feature of ISA 3.1. In ISA 3.1, these accumulators overlapped with the VSX
vector registers 0..31, but logically the accumulator registers were separate
from the FPR registers. In ISA 3.1, it was anticipated that in
This patch enables generating load and store vector pair instructions when
doing certain memory copy operations when -mcpu=future is used. In doing tests
on power10, it was determined that using these instructions were problematical
in a few cases, so we disabled generating them by default. This
These patches implement support for potential future PowerPC cpus. At this
time, features enabled with -mcpu=future may or may not be in actual PowerPCs
that will be delivered in the future.
This patch adds support for the -mcpu=future and -mtune=future options.
If you use -mcpu=future, the
These patches were originally posted on November 10th. Segher has asked that I
repost them. These patches are somewhat changed since the original posting to
address some of the comments.
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605581.html
In the first patch (adding
This patch reworks how the complex multiply and divide built-in functions are
done. Previously we created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit. The old code also did not
support __ibm128 complex multiply and divide if long
This patch is a repost of a patch:
| Date: Thu, 19 Jan 2023 11:37:27 -0500
| Subject: [PATCH] PR target/107299: Fix build issue when long double is IEEE
128-bit
| Message-ID:
This patch updates the IEEE 128-bit types used in libgcc.
At the moment, we cannot build GCC when the target uses IEEE
I'm reposting these two patches that allow GCC to build on Fedora 36 just to be
clear which patches I'm talking about. The issue is that if GCC is configured
with long double using the IEEE 128-bit representation, it currently cannot
build _mulkc3 and _divkc3 in libgcc.
Note, these patches do
The new __dmr type that is being added as a possible future PowerPC instruction
set bumps into a structure field size issue. The size of the __dmr type is
1024 bits.
The precision field in tree_type_common is currently 10 bits, so if you store
1,024 into field, you get a 0 back. When you get 0
On Sun, Jan 29, 2023 at 09:52:38PM -0500, Michael Meissner wrote:
> On Sat, Jan 28, 2023 at 02:29:04AM -0500, Michael Meissner wrote:
> > On Fri, Jan 27, 2023 at 01:59:00PM -0600, Segher Boessenkool wrote:
> > > > There is one bug that I noticed. When you use the full DMR instruction
> > > > the
On Sat, Jan 28, 2023 at 02:29:04AM -0500, Michael Meissner wrote:
> On Fri, Jan 27, 2023 at 01:59:00PM -0600, Segher Boessenkool wrote:
> > > There is one bug that I noticed. When you use the full DMR instruction
> > > the
> > > constant copy propagation patch issues internal errors. I believe
On Fri, Jan 27, 2023 at 01:59:00PM -0600, Segher Boessenkool wrote:
> > There is one bug that I noticed. When you use the full DMR instruction the
> > constant copy propagation patch issues internal errors. I believe this is
> > due
> > to the CCP pass not handling opaque types cleanly enough,
Ping patch. We really would like to get these possible future PowerPC insn
changes into GCC 13.
| Date: Sat, 12 Nov 2022 00:10:59 -0500
| Subject: [PATCH 8] PowerPC: Support load/store vector with right length.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
Ping patch. We really would like to get these possibly future PowerPC insns
into GCC 13.
| Date: Sat, 12 Nov 2022 00:07:55 -0500
| Subject: [PATCH 7] PowerPC: Add -mcpu=future saturating subtract built-ins.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
Ping patch. We really would like to get these possibly future PowerPC insns
into GCC 13.
| Date: Wed, 9 Nov 2022 21:52:49 -0500
| Subject: [PATCH 6/6] PowerPC: Add support for 1,024 bit DMR registers.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email:
Ping patch. We really would like to get these possibly future PowerPC insns
into GCC 13.
| Date: Wed, 9 Nov 2022 21:51:48 -0500
| Subject: [PATCH 5/6] PowerPC: Switch to dense math names for all MMA
operations.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
Ping patch. We really would like to get these possibly future PowerPC insns
into GCC 13.
| Date: Wed, 9 Nov 2022 21:50:24 -0500
| Subject: [PATCH 4/6] PowerPC: Make MMA insns support DMR registers
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email:
Ping patch. We really would like to get these possibly future PowerPC patches
into GCC 13.
| Date: Wed, 9 Nov 2022 21:46:36 -0500
| Subject: [PATCH 3/6] PowerPC: Add support for accumulators in DMR registers.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
Ping patch. We really would like to get these possible future PowerPC patches
into GCC 13.
| Date: Wed, 9 Nov 2022 21:45:39 -0500
| Subject: [PATCH 2/6] PowerPC: Make -mcpu=future enable
-mblock-ops-vector-pair.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA,
Ping patch. We really would like the patches to enable the possible future
MMA+ instructions into GCC 13.
| Date: Wed, 9 Nov 2022 21:44:39 -0500
| Subject: [PATCH 1/6] PowerPC: Add -mcpu=future
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email:
This patch updates the IEEE 128-bit types used in libgcc.
At the moment, we cannot build GCC when the target uses IEEE 128-bit long
doubles, such as building the compiler for a native Fedora 36 system. The
build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
This patch
On Tue, Jan 17, 2023 at 03:57:24PM -0500, Michael Meissner wrote:
> So I have objection to the change. I suspect it may be better with a check
> for
> just optimize either for speed or size, and not for speed.
Sigh. I meant I have NO objection to the change. Sorry about that.
--
Michael
On Mon, Jan 16, 2023 at 05:39:04PM +0800, Kewen.Lin wrote:
> Hi,
>
> Now we will check optimize_function_for_speed_p (cfun) for
> TARGET_SAVE_TOC_INDIRECT if it's implicitly enabled. But
> the effect of -msave-toc-indirect is actually to save the
> TOC in the prologue for indirect calls rather
On Tue, Jan 10, 2023 at 07:23:23PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 09, 2023 at 10:21:52PM -0500, Michael Meissner wrote:
> > I had the patches to change the precision to 128, and I just ran them. C
> > and
> > C++ do not seem to be bothered by changing the precision to 128 (once I got
On Tue, Nov 01, 2022 at 10:42:30PM -0400, Michael Meissner wrote:
> This patch fixes the issue that GCC cannot build when the default long double
> is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
> to buld the __mulkc3 function in libgcc. It is failing in
>
On Fri, Jan 06, 2023 at 07:41:07PM -0500, Michael Meissner wrote:
> On Wed, Dec 21, 2022 at 09:40:24PM +, Joseph Myers wrote:
> > On Wed, 21 Dec 2022, Segher Boessenkool wrote:
> >
> > > > --- a/gcc/tree.cc
> > > > +++ b/gcc/tree.cc
> > > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool
On Wed, Dec 21, 2022 at 09:40:24PM +, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
>
> > > --- a/gcc/tree.cc
> > > +++ b/gcc/tree.cc
> > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > >if (!targetm.floatn_mode (n, extended).exists ())
>
On Wed, Dec 21, 2022 at 09:40:24PM +, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
>
> > > --- a/gcc/tree.cc
> > > +++ b/gcc/tree.cc
> > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > >if (!targetm.floatn_mode (n, extended).exists ())
>
On Fri, Dec 16, 2022 at 11:55:27AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 15, 2022 at 07:09:38PM -0500, Michael Meissner wrote:
> > On Thu, Dec 15, 2022 at 11:59:49AM -0600, Segher Boessenkool wrote:
> > > On Wed, Dec 14, 2022 at 10:36:03AM +0100, Jakub Jelinek wrote:
> > > > The
On Thu, Dec 15, 2022 at 11:59:49AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 14, 2022 at 10:36:03AM +0100, Jakub Jelinek wrote:
> > On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote:
> > > Since function useless_type_conversion_p considers two float types are
This patch fixes two tests that are still failing when long double is IEEE
128-bit after the previous 2 patches for PR target/107299 have been applied.
The tests are:
gcc.target/powerpc/convert-fp-128.c
gcc.target/powerpc/pr85657-3.c
This patch is a rewrite of the patch submitted
This patch fixes the issue that GCC cannot build when the default long double
is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
to buld the __mulkc3 function in libgcc. It is failing in gimple-range-fold.cc
during the evrp pass. Ultimately it is failing because the
This patch reworks how the complex multiply and divide built-in functions are
done. Previously we created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit. The old code also did not
support __ibm128 complex multiply and divide if long
This set of patches was first submitted on November 1st. Kewen.Lin
asked for some changes to the first set of patches. I
also tried to clean up the comments in the second patch about types that Segher
Boessenkool mentioned.
I had just re-submitted the first patch yesterday, but Segher asked
I have submitted a new replacement patch for this patch:
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608368.html
--
Michael Meissner, IBM
PO Box
In the patch I previously submitted:
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID:
Kewen.Lin questioned whether we needed to disable the special handling of the
IEEE 128-bit complex multiply/divide if we
On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote:
> Without or with patch #1, the below ICE in libgcc exists, the ICE should have
> nothing to do with the special handling for building_libgcc in patch #1. I
> think patch #2 which makes _Float128 and __float128 use the same internal
>
On Wed, Dec 07, 2022 at 03:55:41PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> on 2022/12/7 14:44, Michael Meissner wrote:
> > On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
> >> Hi Mike,
> >>
> >> Thanks for fixing this!
> >>
> >> Could you help to elaborate why we need to disable it
On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> Thanks for fixing this!
>
> Could you help to elaborate why we need to disable it during libgcc building?
When you are building libgcc, you are building the __mulkc3, __divkc3
functions. The mapping in the compiler
Ping for patches submitted on November 1st. These 3 patches are needed to be
able to build GCC for PowerPC target systems where long double is configured to
be IEEE 128-bit, such as Fedora 36.
This is the 3rd of 3 patches.
| Date: Tue, 1 Nov 2022 22:44:01 -0400
| Subject: [PATCH 3/3] Update
Ping for patches submitted on November 1st. These 3 patches are needed to be
able to build GCC for PowerPC target systems where long double is configured to
be IEEE 128-bit, such as Fedora 36.
This is for the 2nd of 3 patches.
| Date: Tue, 1 Nov 2022 22:42:30 -0400
| Subject: [PATCH 2/3] Make
Ping for patches submitted on November 1st. These 3 patches are needed to be
able to build GCC for PowerPC target systems where long double is configured to
be IEEE 128-bit, such as Fedora 36.
This is the first patch of 3 patches.
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3]
Can we get the three patches in this patch set reviewed? Without them, GCC 13
can't be built on Fedora 37 which defaults to IEEE 128-bit long double.
| Date: Tue, 1 Nov 2022 22:44:01 -0400
| Subject: [PATCH 3/3] Update float 128-bit conversions, PR target/107299.
| Message-ID:
--
Michael
Can we get the three patches in this patch set reviewed? Without the patches
applied, GCC 13 will not build on Fedora 37, which uses long double defaulting
to IEEE 128-bit.
| Date: Tue, 1 Nov 2022 22:42:30 -0400
| Subject: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299
|
Can we please get this patch reviewed? GCC 13 won't build on Fedora 37 (which
defaults to long double being IEEE 128-bit) without the 3 patches in this set.
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID:
This patch adds support for new instructions that may be added to the PowerPC
architecture in the future to enhance the load and store vector with length
instructions.
The current instructions (lxvl, lxvll, stxvl, and stxvll) are inconvient to use
since the count for the number of bytes must be
This patch adds support for a saturating subtract built-in function that may be
added to a future PowerPC processor. Note, if it is added, the name of the
built-in function may change before GCC 13 is released. If the name changes,
we will submit a patch changing the name.
I also added support
This patch is a prelimianry patch to add the full 1,024 bit dense math register
(DMRs) for -mcpu=future. The MMA 512-bit accumulators map onto the top of the
DMR register.
This patch only adds the new 1,024 bit register support. It does not add
support for any instructions that need 1,024 bit
This patch changes the assembler instruction names for MMA instructions from
the original name used in power10 to the new name when used with the dense math
system. I.e. xvf64gerpp becomes dmxvf64gerpp. The assembler will emit the
same bits for either spelling.
The patches have been tested on
This patch changes the MMA instructions to use either FPR registers
(-mcpu=power10) or DMRs (-mcpu=future). In this patch, the existing MMA
instruction names are used.
A macro (__PPC_DMR__) is defined if the MMA instructions use the DMRs.
The patches have been tested on the following platforms.
The MMA system added the notion of accumulator registers. In power10, these
accumulators overlapped with the FPR registers, but logically the accumulators
were separate from the FPR registers. It is anticipated that in future
systems, we may have a separate dense math unit and the accumulators
This patch enables generating load and store vector pair instructions when
doing certain memory copy operations when -mcpu=future is used. In doing tests
on power10, it was determined that using these instructions were problematical
in a few cases, so we disabled generating them by default. This
This patch adds support for the -mcpu=future and -mtune=future options.
Besides defining __ARCH_PWR_FUTURE__ this particular patch does not enable any
new features.
These patches implement support for potential future PowerPC cpus. At this
time, features enabled with -mcpu=future may or may not
1 - 100 of 632 matches
Mail list logo
