Hi!
On Fri, Jul 18, 2025 at 01:29:07PM +0530, Harish Sadineni wrote:
> > Okay for trunk (with the commit message improved). Thank you!
> Thank you for the review.
> I have updated the commit message as you suggested and sent a v3.
Which I pre-approved, eh :-) And it does look good, please commi
Hi!
On Thu, Jul 17, 2025 at 11:16:07AM +0530, Kishan Parmar wrote:
> I would like to backport patch r15-2928-gbf891fcabca7a5 which is
> available from GCC-15.
>
> In general, if -mcpu=power9, float128 hardware is available, but in the
> case the user explicitly does -mno-float128-hardware or runs
Hi!
On Thu, Jul 17, 2025 at 05:58:47AM -0700, harish.sadin...@windriver.com wrote:
> From: Harish Sadineni
>
> Avoid encoding full build paths into file headers; use only the basename of
> the source file.
Line way too long. Commit message lines are 72 character positions
wide.
(The semicolo
Hi!
On Tue, Jul 01, 2025 at 12:14:32PM -0400, Michael Meissner wrote:
> This patch adds the support that can be used in developing GCC support
> for potential future PowerPC processors.
>
> These changes are being added so that hardware designers can evaluate
> potential new features to be added
Hi!
As always, thank you :-)
On Fri, Jul 11, 2025 at 02:43:12PM -0400, Vladimir Makarov wrote:
> gcc/ChangeLog:
>
> * lra-constraints.cc (process_address_1): When changing base reg
> on a reg of the base class, fall back to reload of whole inner
> address.
>
Hi!
On Sat, Jul 12, 2025 at 09:47:53PM +0800, Xi Ruoyao wrote:
> On Fri, 2025-07-11 at 14:01 -0500, Peter Bergner wrote:
> > On 7/11/25 10:22 AM, Vladimir Makarov wrote:
> > > On 7/8/25 9:43 PM, Xi Ruoyao wrote:
> > > >
> > > > IIUC "recog does not look at constraints until reload" has been a
> >
Hi Surya, Jeevitha,
On Thu, Jul 10, 2025 at 08:26:51PM +0530, Surya Kumari Jangala wrote:
> On 24/06/25 3:30 pm, jeevitha wrote:
> > The following patch has been tested on powerpc64le-linux and verified it's
> > fixed.
> >
> > Changes from V1:
> > Added the reason for adding the flag(-fno-ipa-icf
Hi!
On Thu, Jul 10, 2025 at 12:10:16PM +, Sadineni, Harish wrote:
> Ping for [1]https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html.
>
> This patch avoids embedding full build paths into generated headers by using
> only the basename of the source file. This helps to improve bui
Hi!
On Wed, Jul 09, 2025 at 08:32:19PM +0530, Kishan Parmar wrote:
> Ping!
>
> Please review.
I did review this, in
Message-ID: <20250626155019.go17...@gate.crashing.org>
Date: Thu, 26 Jun 2025 10:50:19 -0500
https://inbox.sourceware.org/gcc-patches/20250626155019.go17...@gate.crashing.org/
Did
Hi!
On Tue, Jul 08, 2025 at 08:51:30AM +, Cui, Lili wrote:
> > rs6000 does not *have* a hard frame pointer!
>
> Oh, I see. The handling of HARD_FRAME_POINTER_REGNUM seems redundant for
> rs6000.
The Power Architecture, Power ISA, nor any of our ABIs has a frame
pointer. GCC generic code r
Hi!
On Sat, Jul 05, 2025 at 11:10:05PM +0800, Xi Ruoyao wrote:
> Possibly this is https://gcc.gnu.org/PR101882. Specifically comment 5
> from Segher:
>
> "The LRA change is correct AFAICS. But combine makes a change that
> violates the earlyclobber... I need to do something about that, too."
Hi!
On Fri, Jul 04, 2025 at 07:23:23AM +, Cui, Lili wrote:
> > > Initially, I looked at other architectures and disabled the hard frame
> > > pointer,
> >
> > Like aarch? Yeah I always wondered why they don't do it. I decided that
> > that
> > is because of their ABI and architecture stuff
On Wed, Jul 02, 2025 at 01:32:37PM +, Cui, Lili wrote:
> > > + /* Don't mess with the following registers. */ if
> > > + (frame_pointer_needed)
> > > +bitmap_clear_bit (components, HARD_FRAME_POINTER_REGNUM);
> >
> > What is that about? Isn't that one of the bigger possible wins?
>
>
On Wed, Jul 02, 2025 at 11:06:38AM +0200, Jakub Jelinek wrote:
> On Tue, Jul 01, 2025 at 02:50:40PM -0500, Segher Boessenkool wrote:
> > No tests become good tests without effort. And tests that are not good
> > tests require constant maintenance!
>
> Here are two patches,
Hi!
On Tue, Jul 01, 2025 at 08:39:26PM +0200, Jakub Jelinek wrote:
> On Tue, Jul 01, 2025 at 12:04:04PM -0500, Segher Boessenkool wrote:
> > On Mon, Feb 17, 2025 at 02:28:50PM +, Alex Coplan wrote:
> > > After the recent alignment peeling enhancements in the vectorize
Hi!
On Tue, Jul 01, 2025 at 05:16:45PM +0200, Jakub Jelinek wrote:
> This test seems to fail when testing with
> RUNTESTFLAGS="--target_board=unix/'{,-fstack-protector-strong}'"
> on power10.
Please mention near the start of the commit message (like, in the
subject already!) that the testcase did
Hi!
On Mon, Feb 17, 2025 at 02:28:50PM +, Alex Coplan wrote:
> After the recent alignment peeling enhancements in the vectorizer we
> started vectorizing the "checking" loops (that check for the right
> result) in gcc.target/powerpc/vsx-vectorize-*.c, thus skewing the
> expected counts of var
Hi!
On Tue, Jun 17, 2025 at 10:03:28PM +0800, Cui, Lili wrote:
> Collected spec2017 performance on ZNVER5, EMR and ICELAKE. No performance
> regression was observed.
> For O2 multi-copy :
> 511.povray_r improved by 2.8% on ZNVER5.
> 511.povray_r improved by 4.2% on EMR
No huge improvement, but n
Hi!
On Wed, Jun 25, 2025 at 02:50:14PM -0400, Michael Meissner wrote:
> This is patch #1 of 3 that adds the support that can be used in developing GCC
> support for potential future PowerPC processors. With all 3 patches, the
> tuning
> for the 'future' processor is the same as power10 and power
Hi!
[ Please don't say "patch v1", it's just clutter. ]
The point of the patch is to improve some code that evokes undefined
behaviour. The sanitizer for that is how these problems were found,
you can remark that somewhere later in the message, but ubsan is not
what this patch is about, it does
Hi!
On Mon, Jun 23, 2025 at 07:30:51PM +0530, Surya Kumari Jangala wrote:
> On 14/06/25 2:07 pm, Michael Meissner wrote:
> > @@ -119,6 +122,7 @@
> > | OPTION_MASK_FLOAT128_HW \
> > | OPTION_MASK_FLOAT128_KEYWORD \
> >
Hi!
On Fri, Jun 20, 2025 at 10:38:30PM +0530, Surya Kumari Jangala wrote:
> On 14/06/25 2:13 pm, Michael Meissner wrote:
> > This is patch #4 of 4 to add -mcpu=future support to the PowerPC.
>
> I think this should be a separate patch in itself. As such, this
> patch is not required to enable the
On Mon, Jun 16, 2025 at 08:34:23PM +0200, Martin Uecker wrote:
> Am Montag, dem 16.06.2025 um 12:56 -0500 schrieb Segher Boessenkool:
> > So, now the warning no longer does what the name says, or what its
> > documentation says. Please update the documentation at least!
>
&g
Hi!
On Sun, Jun 15, 2025 at 04:18:36PM +0200, Martin Uecker wrote:
> Instead of adding it to -Wextra, here is my attempt to improve this
> warning as discussed in the PR and make it suitable for -Wall.
> There were only two tests I had to add -Wno-jump-misses-init.
>
> Bootstrapped and regressio
On Wed, Jun 04, 2025 at 03:47:31PM +, Alfie Richards wrote:
> Hi,
>
> This fixes the FMV powerpc tests I recently committed, and hopefully makes
> them
> work on a wider range of target configurations.
>
> I plan to commit this on Monday if no one has any objections.
I, the sole maintainer
On Mon, Jun 09, 2025 at 08:26:10AM -0600, Jeff Law wrote:
> On 4/1/25 9:35 PM, Jeff Law wrote:
> So returning to this
>
> So the combine pass doesn't reject combination into an ASM_INPUT, just
> combination from most ASM_INPUTs.
Yeah, exactly.
> It does rely on predicates to determine valid
Hi!
On Tue, Apr 01, 2025 at 09:35:53PM -0600, Jeff Law wrote:
> Segher -- there's a combine question near the end...
> So this is a nasty little problem and touches on a deeper issue.
>
> The core problem is that combine doesn't know anything about
> constraints. It works with predicates and c
Hi!
On Mon, Jun 02, 2025 at 08:37:19PM +0200, Martin Uecker wrote:
> Am Montag, dem 02.06.2025 um 13:19 -0500 schrieb Segher Boessenkool:
> > On Mon, Jun 02, 2025 at 05:50:08PM +0200, Martin Uecker wrote:
> > > According to the discussion in the bugzilla there seems to be
>
Hi!
On Mon, Jun 02, 2025 at 05:50:08PM +0200, Martin Uecker wrote:
> According to the discussion in the bugzilla there seems to be
> some consensus to activate the warning for -Wextra (I am also
> looking into implementing the suggested improvements that may
> make it suitable fo r-Wall). When m
On Thu, May 29, 2025 at 03:07:34PM -0500, Peter Bergner wrote:
> On 5/29/25 5:35 AM, Segher Boessenkool wrote:
> >
> > Add yourself to suthors as well?
>
> Agreed. Just add your name/email address directly under mine, like so:
>
> 2025-05-29 Peter Bergner
>
Hi!
On Thu, May 29, 2025 at 10:36:12AM +0530, jeevitha wrote:
> Changes to amo.h include the addition of the following load atomic operations:
> Compare and Swap Not Equal, Fetch and Increment Bounded, Fetch and Increment
> Equal, and Fetch and Decrement Bounded. Additionally, Store Twin is added
As one of the last steps in removing old reload, I'll delete the reload.h
header file. It would be a bit embarrassing if that stopped the target I am
responsible for from working, so let's prevent that.
We do not actually use anything from this header file (checked by building
with this patch, an
s
Hi!
On Thu, May 08, 2025 at 07:44:26PM -0400, Michael Meissner wrote:
> In bug PR target/118541 on power9, power10, and power11 systems, for the
> function:
>
> extern double __ieee754_acos (double);
>
> double
> __acospi (double x)
> {
> double ret =
Hi!
On Wed, May 21, 2025 at 06:27:38AM +0200, Richard Biener wrote:
> On Wed, May 21, 2025 at 12:30 AM Segher Boessenkool
> wrote:
> >
> > On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> > > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jan
On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > Hi Mike,
> > Irrespective of whether -Ofast is used or not, should’nt we generate
> > XSCMPUDP instruction for ‘isgreater()’ operation? This is because XSCM
Hi!
On Thu, May 08, 2025 at 08:07:04PM -0400, Michael Meissner wrote:
> Previously GCC would zero externd a DImode GPR value to TImode by first zero
> extending the DImode value into a GPR TImode value, and then do a MTVSRDD to
> move this value to a VSX register.
>
> This patch does the move dir
On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > Hi Mike,
> > Irrespective of whether -Ofast is used or not, should’nt we generate
> > XSCMPUDP instruction for ‘isgreater()’ operation? This is because XSCM
On Tue, May 06, 2025 at 02:09:45PM -0400, Paul Koning wrote:
> > It is pretty hard to work with double-indirect things, often have to
> > make sure the two memory accesses are not to the same address, etc.
>
> Types will prevent that, typically, but in any case double indirect like that
> is stil
On Sat, May 03, 2025 at 07:42:22AM -0600, Jeff Law wrote:
> On 5/3/25 4:52 AM, Richard Biener wrote:
> >On Fri, 2 May 2025, Paul Koning wrote:
> >>>On May 2, 2025, at 12:27 PM, Maciej W. Rozycki
> >>>wrote:
> >>Indeed, I have noticed that LRA doesn't take advantage of PDP-11 (and I
> >>would gues
Hi!
On Fri, May 02, 2025 at 12:11:37PM +0200, Richard Biener wrote:
> This mini-series removes the TARGET_LRA_P hook, forcing all targets
> to use LRA. I have not touched the targets that define -mlra
> in terms of a 'Target Mask(XXX)' since IIRC there's no way to
> "default" that. I'd expect th
On Fri, May 02, 2025 at 12:26:12PM +0200, Richard Biener wrote:
> The following amends gcc-15/changes.html with a note that reload
> is going to be removed for GCC 16.
Thank you! The patches are taking a little time, I gave up on rebasing
what I had, redoing it is less work. Oh well.
> OK for w
On Wed, Mar 26, 2025 at 09:01:43AM +0100, Jakub Jelinek wrote:
> The following testcase FAILs because the always_inline function can't
> be inlined.
> The rs6000 backend has similarly to other targets a hook which rejects
> inlining which would bring in new ISAs which aren't there in the caller.
>
On Tue, Mar 25, 2025 at 07:00:34PM -0500, Peter Bergner wrote:
> On 3/25/25 5:17 PM, Segher Boessenkool wrote:
> > On Tue, Mar 25, 2025 at 03:33:59PM -0500, Peter Bergner wrote:
> >> Segher, any reason you can give on why we shouldn't go the easy route to
> >>
On Tue, Mar 25, 2025 at 03:33:59PM -0500, Peter Bergner wrote:
> On 3/25/25 1:42 AM, jeevitha wrote:
> > gcc/testsuite/
> > PR testsuite/119382
> > * gcc.target/powerpc/vsx-builtin-7.c: Add '-fno-ipa-icf' to dg-options.
> >
> > diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
Happy new year!
Sorry it took so long.
On Tue, Oct 15, 2024 at 12:49:49PM +0530, jeevitha wrote:
> Hi All,
> options by removing -mpower9-misc and -mvsx, which are enabled by default with
> -mdejagnu-cpu=power9. The has_arch_pwr9 check is also true with
> -mdejagnu-cpu=power9, so it has been remo
On Fri, Nov 08, 2024 at 02:28:11PM -0600, Peter Bergner wrote:
> On 11/8/24 1:44 PM, Michael Meissner wrote:
> > diff --git a/gcc/config/rs6000/rs6000-arch.def
> > b/gcc/config/rs6000/rs6000-arch.def
> > new file mode 100644
> > index 000..e5b6e958133
> > --- /dev/null
> > +++ b/gcc/config
On Tue, Nov 05, 2024 at 04:26:13PM -0600, Peter Bergner wrote:
> On 11/5/24 1:16 PM, Segher Boessenkool wrote:
> > Would it not have been better to not use -O0 at all here? -O0 is
> > not realistic if you expect any reasonable optimisation!
>
> That's what I first att
On Tue, Nov 05, 2024 at 10:47:28AM -0600, Peter Bergner wrote:
> The test safe-indirect-jump-3.c FAILs on powerpc64le-linux with the change
> in jump table generation behavior with commit r15-4756-g06bc3a734e8890,
> since it is compiled without optimization and expects jump tables to be
> generated
Hi!
On Mon, Oct 14, 2024 at 05:26:51PM +0530, jeevitha wrote:
> Corrected the function code for the Atomic Memory Operation "Fetch and
> Decrement
> Bounded", changing it from 0x1A to 0x1C.
... which is the correct value. :-)
> 2024-10-14 Jeevitha Palanisamy
>
> gcc/
> * config/rs6000/
On Thu, Mar 21, 2024 at 06:21:48PM +0530, jeevitha wrote:
Hi!
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
Please send v2 patches as their own, new thread. Replies are for
replies (duh), and for patch series. If you mix several versions in one
thread things be
On Wed, Sep 18, 2024 at 01:51:21AM -0400, Michael Meissner wrote:
> On Tue, Sep 17, 2024 at 02:33:09AM -0500, Segher Boessenkool wrote:
> > Hi!
> >
> > On Mon, Sep 16, 2024 at 11:40:45PM -0400, Michael Meissner wrote:
> > > With this patch, GCC now realizes that the
Hi!
On Mon, Sep 16, 2024 at 11:40:45PM -0400, Michael Meissner wrote:
> With this patch, GCC now realizes that the vector shift instructions will look
> at the bottom 6 bits for the shift count, and it can use either a VSPLTISW or
> XXSPLTIB instruction to load the shift count.
Do we do something
Hi!
On Thu, Aug 22, 2024 at 08:48:19PM -0500, Peter Bergner wrote:
> I was a little surprised we didn't have that macro already. Ok, consider
> it changed with your suggestion.
>
> I agree, there probably is code in the backend that currently handles TImode
> that should probably be changed to h
Hi!
On Thu, Aug 22, 2024 at 05:39:36PM +0800, Kewen.Lin wrote:
> > - if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
> > + if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
> > + || mode == PTImode)
>
> Maybe we can introduce a macro to this file like
>
On Mon, Aug 12, 2024 at 10:59:01AM -0500, Peter Bergner wrote:
> Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
>
> Segher, this resolves the issues you mentioned in your review.
> This was on the top of your patch review queue before, so maybe
> we have queue overf
On Mon, Aug 12, 2024 at 08:48:22AM -0500, Peter Bergner wrote:
> On 8/11/24 9:42 PM, Kewen.Lin wrote:
> > One difference with this change is that previously users specify -mno-vsx to
> > disable all vector insns (both VMX and VSX) on Power[89], now they should
> > use -mno-altivec for that purpose.
Hi!
On Mon, Aug 12, 2024 at 10:42:48AM +0800, Kewen.Lin wrote:
> on 2024/8/10 05:43, Segher Boessenkool wrote:
> IIUC, we want to split TARGET_P[89]_VECTOR into TARGET_P[89]_ALTIVEC and
> TARGET_P[89]_VSX (or just TARGET_POWER[89] && TARGET_VSX or TARGET_ALTIVEC)
> according
Hi!
On Mon, Aug 12, 2024 at 09:55:07AM +0100, Richard Sandiford wrote:
> "Kewen.Lin" writes:
> > (define_insn "*vsx_le_perm_store_"
> > [(set (match_operand:VSX_LE_128 0 "memory_operand" "=Z,Q")
> > (match_operand:VSX_LE_128 1 "vsx_register_operand" "+wa,r"))]
>
> Is it well-formed to
On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote:
> On 8/9/24 12:54 PM, Segher Boessenkool wrote:
> >> --- a/gcc/config/rs6000/altivec.md
> >> +++ b/gcc/config/rs6000/altivec.md
> >> @@ -623,7 +623,7 @@ (define_insn "altivec_eqv1ti&q
Hi!
On Fri, Aug 09, 2024 at 05:50:18PM +0800, Kewen.Lin wrote:
> As PR116266 shows, we miss TARGET_P10_VECTOR to guard those
> Power10 related vector instructions as well as their
> according built-in functions. This patch is to introduce
> TARGET_P10_VECTOR which is actually TARGET_POWER10 &&
>
Hi!
On Wed, Jul 24, 2024 at 11:38:11AM -0700, Carl Love wrote:
> On 7/24/24 10:03 AM, Segher Boessenkool wrote:
> >So much manual stuff needed, sigh.
> >
> >On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote:
> >>gcc/ChangeLog:
> >> * c
On Wed, Jul 24, 2024 at 12:16:33PM -0500, Peter Bergner wrote:
>
> On 7/24/24 12:03 PM, Segher Boessenkool wrote:
> >> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
> >
> > Why the -save-temps? Always document it if you want that for something,
On Wed, Jul 24, 2024 at 12:12:05PM -0500, Peter Bergner wrote:
> On 7/24/24 12:06 PM, Segher Boessenkool wrote:
> I thought we always wanted the predicate to match the constraint being used?
Predicates and constraints have different purposes, and are used at
different times (typ
On Tue, Jul 23, 2024 at 04:26:43PM -0500, Peter Bergner wrote:
> On 7/19/24 3:04 PM, Carl Love wrote:
> > diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> > index 5af9bf920a2..2a18ee44526 100644
> > --- a/gcc/config/rs6000/altivec.md
> > +++ b/gcc/config/rs6000/altivec.md
Hi!
So much manual stuff needed, sigh.
On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote:
> gcc/ChangeLog:
> * config/rs6000/altivec.md (vsdb_): Change
> define_insn iterator to VEC_IC.
>From VI2 (a nothing-saying name) to VEC_IC (also a nonsensical name).
Maybe VEC_IC should ha
On Thu, Jul 18, 2024 at 09:53:05AM -0500, Peter Bergner wrote:
> On 7/18/24 8:23 AM, Segher Boessenkool wrote:
> > Everything in gcc.target/powerpc is only run for target powerpc*-*-*
> > anyway, so make this just
> >
> > /* { dg-do compile } */
> >
> >
Hi!
On Wed, Jul 10, 2024 at 01:39:05PM -0400, Michael Meissner wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/power11-1.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target powerpc*-*-* } } */
Everything in gcc.target/powerpc is only run for target powerpc*-*-*
anyway, so make thi
Hi!
On Wed, Jul 10, 2024 at 01:35:47PM -0400, Michael Meissner wrote:
> * config/rs6000/power10.md (all reservations): Add power11 as an
> alternative to power10.
That is not a great description of what is actually going on. Just
"Add power11." would be better :-) Or "Add power11 be
Hi!
[ I reviewed this together with Ke Wen. All blame should go to me, all
praise to him. ]
On Wed, Jul 10, 2024 at 01:34:26PM -0400, Michael Meissner wrote:
> [This is a repost of the June 4th patch]
It is not a repost. It is v2. It has important changes.
> * config.gcc (rs6000*-*-*
Hi!
On Wed, Jul 10, 2024 at 01:32:02PM -0400, Michael Meissner wrote:
> Note, this is a repost of the 3 patches I posted on June 4th. The first two
> patches are the same. The third patch modifies the power11 tests to do a
> compile instead of assemble, and I removed the power11 specific target
Hi!
On Mon, Jul 01, 2024 at 02:17:33PM +0800, Kewen.Lin wrote:
> * config/rs6000/rs6000-builtins.def: Update some bif expanders by
> replacing orc3 with iorc3.
> * config/rs6000/rs6000-string.cc (expand_cmp_vec_sequence): Update gen
> function by replacing orc3 with iorc3.
On Mon, Jul 01, 2024 at 04:36:44PM +0200, Richard Biener wrote:
> On Mon, Jul 1, 2024 at 8:17 AM Kewen.Lin wrote:
> > As PR115659 shows, assuming c = x CMP y, there are some
> > folding chances for patterns r = c ? 0/z : z/-1:
> > - For r = c ? 0 : z, it can be folded into r = ~c & z.
> > - Fo
I didn't see this before. Sigh.
On Tue, Jan 02, 2024 at 09:47:11AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> >> This patch adds a combine pass that runs late in the pipeline.
>
Hi!
On Thu, Jun 20, 2024 at 06:22:07PM +0800, Kewen.Lin wrote:
> Following your review comments in [1], this patch is
> separated from Xionghu's patch v4 [2] and mainly targetted
> for 32-bit element size, it changes with the generic call
> altivec_vmrg*w in vec_widen_[su]mult_{hi,lo}* expanders a
On Tue, Jun 18, 2024 at 12:53:09PM -0500, Peter Bergner wrote:
> On 6/18/24 8:20 AM, Segher Boessenkool wrote:
> > On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
> >> So we should be able to shrink-wrap in the presence of the ROP protection.
> [snip]
> &
On Fri, Feb 10, 2023 at 10:59:52AM +0800, Xionghu Luo via Gcc-patches wrote:
So, nothing here is obvious at all still. Could you please split it up
a bit more, so that every step is either small or simple?
So maybe first just split patterns to BE and LE versions, and nothing
else?
And one patch
On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
> On 6/17/24 7:57 PM, Segher Boessenkool wrote:
> > On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
> >> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> >> Yeah, I didn't write that, I
Hi!
On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> >> - /* If we are inserting ROP-protect instructions, disable shrink wrap.
> >> */
> >> - if (rs6000_rop_protect)
> >> -flag_shrink_
Hi!
On Mon, Jun 17, 2024 at 05:26:39PM -0500, Peter Bergner wrote:
> While auditing our ROP code generation for some test cases I wrote, I noticed
> a few issues which I'm tracking in PR114759. The first issue I noticed is we
> disable shrink-wrapping when using -mrop-protect, even in the cases w
Hi!
Thanks for posting this again. Much easier to find that way :-)
On Mon, Jun 17, 2024 at 07:15:48PM +0200, Jakub Jelinek wrote:
> While my r15-1001-g4cf2de9b5268224 PCH PIE power fix change decreased the
> .data section sizes (219792 -> 189336), it increased the size of already
> huge rs6000_
On Mon, Jun 17, 2024 at 03:26:52PM +0200, Jakub Jelinek wrote:
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html
> patch. While the committed and backported patch fixed PCH on PIE
> cc1/cc1plus etc. on PowerPC, it grew up the size of the
> rs6000_init_generat
Hi!
On Fri, Jun 14, 2024 at 11:37:46AM -0700, Carl Love wrote:
> /* { dg-do run } */
> -/* { dg-options "-mvsx" } */
> -/* { dg-additional-options "-mdejagnu-cpu=power8" { target { ! has_arch_pwr8
> } } } */
> -/* { dg-require-effective-target powerpc_vsx } */
> +/* { dg-options "-O2 -mdejagnu-c
Hi!
On Thu, Jun 13, 2024 at 11:32:58AM -0700, Carl Love wrote:
> The test gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c is supposed to
> be a runnable test
> to verify the execution of the vec_unpackl and vec_unpackh built-ins. The
> dg-do command is set to
> compile not run. This patc
On Wed, Jun 12, 2024 at 07:02:31PM -0500, Peter Bergner wrote:
> On 6/12/24 3:00 PM, Segher Boessenkool wrote:
> >> /* { dg-do compile { target { powerpc64*-*-* } } } */
> >
> > Probably should be an "lp64" instead?
>
> Actually, there is nothing in
Hi!
On Wed, Jun 12, 2024 at 02:49:40PM -0500, Peter Bergner wrote:
> testsuite: Fix pr66144-3.c test to accept multiple equivalent insns.
> [PR115262]
("rs6000:", not "testsuite")
> Jeff's commit r15-831-g05daf617ea22e1 changed the instruction we expected
> for this test case into an equivalent
Hi!
What does "powerpc < 7" mean? Something before POWER ISA 2.06?
On Tue, Jun 11, 2024 at 04:22:54PM +0200, Rene Rebe wrote:
> Glibc uses .machine to determine assembler optimizations to use.
What does this mean?
.machine is an *output* for glibc; nothing in glibc reads source code.
Nothing
Hi!
On Tue, Jun 11, 2024 at 04:37:25PM +0800, Jiufu Guo wrote:
> Sometimes, a complicated constant is built via 3(or more)
> instructions. Generally speaking, it would not be as fast
> as loading it from the constant pool (as the discussions in
> PR63281):
> "ld" is one instruction. If consider
Hi!
On Mon, Jun 03, 2024 at 04:55:05PM +0200, Jakub Jelinek wrote:
> PCH doesn't work properly in --enable-host-pie configurations on
> powerpc*-linux*.
PCH and PIE, two of my favourites ;-)
> For PCH though it actually results in saving those huge arrays (one is
> 130832 bytes, another 81568 by
On Fri, May 31, 2024 at 09:14:21AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Hi!
> >
> > On Fri, May 31, 2024 at 01:21:44AM +0530, Ajit Agarwal wrote:
> >> Code is implemented with pure virtual functions to interface with target
> >>
Hi!
On Fri, May 31, 2024 at 01:21:44AM +0530, Ajit Agarwal wrote:
> Code is implemented with pure virtual functions to interface with target
> code.
It's not a pure function. A pure function -- by definition -- has no
side effects. These things have side effects.
What you mean is this is *an i
Hi Alex,
On Thu, May 30, 2024 at 01:40:27PM -0300, Alexandre Oliva wrote:
> Sorry, I misnumbered this patch as #1/2 when first posting v3.
I see at least five completely different patches in this email thread,
with different subjects and all.
> On May 28, 2024, Segher Boessenkool
On Wed, May 29, 2024 at 03:52:15AM -0300, Alexandre Oliva wrote:
> On May 27, 2024, "Kewen.Lin" wrote:
>
> > I wonder if it's possible to have a test case for this?
>
> gcc.dg/guality/pr54519-[34].c at -O[1g] are fixed by this patch on
> ppc64le-linux-gnu. Are these the sort of test case you're
Hi!
On Mon, May 27, 2024 at 05:37:23PM +0800, HAO CHEN GUI wrote:
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -2459,8 +2459,9 @@ interclass_mathfn_icode (tree arg, tree fndecl)
>errno_set = true; builtin_optab = ilogb_optab; break;
> CASE_FLT_FN (BUILT_IN_ISINF):
>bui
On Tue, May 28, 2024 at 02:09:50PM +0200, Richard Biener wrote:
> On Tue, May 28, 2024 at 9:09 AM Kewen.Lin wrote:
> > As Haochen's previous reply, I think there are three cases:
> > 1) no optab defined, fold in a generic way;
> > 2) optab defined, SUCC, expand as what it defines;
> > 3) opt
On Sat, May 25, 2024 at 09:13:12AM -0300, Alexandre Oliva wrote:
> Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
> out of a single call insn, but the call (bl) or jump (b) is not always
> the last opcode in the sequence.
> This does not seem to be a problem for exception h
On Sat, May 25, 2024 at 09:12:05AM -0300, Alexandre Oliva wrote:
You sent multiple patch series in one thread, and multiple versions of
the same series even.
This is very hard to even *read*, let alone work with. Please don't.
Segher
Hi!
On Wed, May 22, 2024 at 09:29:13AM -0500, Peter Bergner wrote:
> On 5/21/24 8:27 AM, jeevitha wrote:
> > The following patch has been bootstrapped and regtested with default
> > configuration
> > [--enable-checking=yes] and with --enable-checking=release on
> > powerpc64le-linux.
> >
> > Th
On Fri, May 17, 2024 at 10:38:54AM +0800, HAO CHEN GUI wrote:
> This expand calls gen_xststdcp which is a P9 vector instruction and
> relies on "TARGET_P9_VECTOR". So I set the condition.
Why? It needs P9, sure, and MSR[VSX] set, but the operands being VSX
registers takes care of that, heh.
But
Hi!
On Fri, Apr 12, 2024 at 04:24:23PM +0800, HAO CHEN GUI wrote:
> This patch implemented optab_isnormal for SF/DF/TFmode by rs6000 test
> data class instructions.
>
> This patch relies on former patch which adds optab_isnormal.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649366.h
Hi!
On Thu, May 16, 2024 at 02:56:49PM +0800, Jiufu Guo wrote:
> Jiufu Guo writes:
> > Segher Boessenkool writes:
> >> On Tue, May 14, 2024 at 05:53:56PM +0800, Jiufu Guo wrote:
> >>> Thanks so much for your great review!
> >>> Reference other messages
1 - 100 of 1202 matches
Mail list logo
