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):
>
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)
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
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.
> >
> >
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.
>
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 messa
On Tue, May 14, 2024 at 05:53:56PM +0800, Jiufu Guo wrote:
> Thanks so much for your great review!
> Reference other messages, I'm wondering "invalid %%a value" may be
> acceptable, or "invalid %%a address expression in TOC" maybe better.
"%%a requires a memory operand"? Maybe even print out the
Oh, btw:
On Tue, May 14, 2024 at 11:00:38AM +0800, Jiufu Guo wrote:
> >> --- a/gcc/config/rs6000/rs6000.cc
> >> +++ b/gcc/config/rs6000/rs6000.cc
> >> @@ -14659,6 +14659,12 @@ print_operand_address (FILE *file, rtx x)
> >>else if (SYMBOL_REF_P (x) || GET_CODE (x) == CONST
> >> ||
On Tue, May 14, 2024 at 11:00:38AM +0800, Jiufu Guo wrote:
> >> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> >> index 117999613d8..50943d76f79 100644
> >> --- a/gcc/config/rs6000/rs6000.cc
> >> +++ b/gcc/config/rs6000/rs6000.cc
> >> @@ -14659,6 +14659,12 @@
Hi!
On Mon, May 13, 2024 at 10:57:12AM +0800, Jiufu Guo wrote:
> For PR96866, when gcc print asm code for modifier "%a" which requires
> an address operand,
It requires a *memory* operand, and it outputs its address. This is a
generic modifier btw (not rs6000).
> while the operand is with the
On Fri, May 10, 2024 at 02:50:56PM +0200, Richard Biener wrote:
> But for example a reg-reg move when optimizing for speed could have
> a zero associated cost.
Sure, but this is the way things always have been. I'm sure there are
ways to change things so they become slightly easier to use, but
On Fri, May 10, 2024 at 12:19:35PM +0200, Richard Biener wrote:
> On Fri, May 10, 2024 at 11:06 AM Segher Boessenkool
> wrote:
> > *All* code using a cost will have to be inspected and possibly adjusted
> > if you decide to use a different value for "unknown" than w
On Fri, May 10, 2024 at 04:50:10PM +0800, HAO CHEN GUI wrote:
> Hi Richard,
> Thanks for your comments.
>
> 在 2024/5/10 15:16, Richard Biener 写道:
> > But if targets return sth < COSTS_N_INSNS (1) but > 0 this is now no
> > longer meaningful. So shouldn't it instead be
> >
> > return cost >
Hi!
On Fri, May 10, 2024 at 09:16:26AM +0200, Richard Biener wrote:
> On Fri, May 10, 2024 at 4:25 AM HAO CHEN GUI wrote:
> >But if set_src_cost returns a value less than COSTS_N_INSNS (1), it's
> > untouched and just returned by pattern_cost. Thus "zero" from set_src_cost
> > is higher than
On Thu, May 02, 2024 at 02:38:12PM -0600, Jeff Law wrote:
>
>
> On 5/2/24 12:59 PM, Vineet Gupta wrote:
> >This is no logic change (but technically still a functional change).
> >
> >Ran into this when stepping thru combine code.
> >@newpat has some random garbage for a bit until it is actually
On Thu, May 02, 2024 at 11:59:24AM -0700, Vineet Gupta wrote:
> This is no logic change (but technically still a functional change).
Where are 1/3 and 2/3? Or are those unrelated? Please don't make
series like that.
> Ran into this when stepping thru combine code.
> @newpat has some random
On Thu, Apr 18, 2024 at 11:14:42AM +0800, Kewen.Lin wrote:
> on 2024/4/18 10:01, HAO CHEN GUI wrote:
> > This patch replace bcdadd. with bcdsub. for bcd invalid number checking.
> > bcdadd on two same numbers might cause overflow which also set
> > overflow/invalid bit so that we can't
Hi!
On Thu, Apr 11, 2024 at 11:23:02PM -0500, Peter Bergner wrote:
> On 4/11/24 10:31 PM, Kewen.Lin wrote:
> >> +;; This option exists only to create its MASK. It is not intended for
> >> users.
> >> +mdo-not-use-this-option
> >> +Target RejectNegative Mask(POWER8) Var(rs6000_isa_flags)
On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote:
> On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
> wrote:
> > This is never okay. You cannot commit a patch without approval, *ever*.
This is the biggest issue, to start with. It is fundamental.
> > That pat
On Sun, Apr 07, 2024 at 08:31:38AM +0200, Uros Bizjak wrote:
> If there are no further comments, I plan to commit the referred patch
> to the mainline on Wednesday. The latest version can be considered an
> obvious patch that solves certain oversight in the original
> implementation.
This is
Hi!
On Fri, Apr 05, 2024 at 04:06:01AM +0200, Hans-Peter Nilsson wrote:
> The xpassing change in generated code was as follows, at
> r14-9788-gb7bd2ec73d66f7 (where I locally applied a revert
> to verify that this suspect was the cause). That was so
> much of an improvement that I had to share
Hi!
On Wed, Apr 03, 2024 at 01:07:41PM +0200, Richard Biener wrote:
> The following avoids re-walking and re-combining the instructions
> between i2 and i3 when the pattern of i2 doesn't change.
>
> Bootstrap and regtest running ontop of a reversal of
> r14-9692-g839bc42772ba7a.
Please include
ot the
way to do it.
Committed to trunk.
Segher
2024-03-27 Segher Boessenkool
PR rtl-optimization/101523
* combine.cc (try_combine): Don't do a 2-insn combination if
it does not in fact change I2.
---
gcc/combine.cc | 11 +++
1 file changed, 11 insertion
On Thu, Mar 07, 2024 at 11:46:54PM +0100, Uros Bizjak wrote:
> > Can't you just describe the dataflow then, without an unspec? An unspec
> > by definition does some (unspecified) operation on the data.
>
> Previously, it was defined as:
>
> (define_insn "*pushfl2"
>[(set (match_operand:W 0
On Thu, Mar 07, 2024 at 11:27:28PM +0100, Uros Bizjak wrote:
> On Thu, Mar 7, 2024 at 11:07 PM Uros Bizjak wrote:
> > > > (unspec:DI [
> > > > (reg:CC 17 flags)
> > > > ] UNSPEC_PUSHFL)
> > >
> > > But that is invalid RTL? The only valid use of a CC is written as
> > >
Hi!
On Fri, Feb 23, 2024 at 03:04:13PM +0530, jeevitha wrote:
> PTImode attribute assists in generating even/odd register pairs on 128 bits.
It is a mode, not an attribute. Attributes are on declarations, while
modes are on a much more fundamental level (every value has a mode, in
GCC!)
> When
On Thu, Mar 07, 2024 at 11:07:18PM +0100, Uros Bizjak wrote:
> On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
> wrote:
> > > but can be something else, such as the above noted
> > >
> > > (unspec:DI [
> > > (reg:CC 17 flags)
> > >
On Fri, Mar 08, 2024 at 03:01:04AM +0530, Ajit Agarwal wrote:
>
> >> + Copyright (C) 2020-2023 Free Software Foundation, Inc.
> >
> > What in here is from 2020?
> >
> > Most things will be from 2024, too. First publication date is what
> > counts.
>
> Please let me know the second
On Thu, Mar 07, 2024 at 10:04:32PM +0100, Uros Bizjak wrote:
[snip]
> The part we want to fix deals with the *user* of the CC register. It
> is not true that this is always COMPARISON_P, so EQ, NE, GE, LT, ...
> in the form of
>
> (LT:CCGC (reg:CCGC 17 flags) (const_int 0))
>
> but can be
On Thu, Mar 07, 2024 at 12:22:04PM +0100, Uros Bizjak wrote:
> As I understood find_single_use, it is returning RTX iff DEST is used
> only a single time in an insn sequence following INSN.
Connected by a log_link even, yeah.
> We can reject the combination without worries of multiple uses.
On Thu, Mar 07, 2024 at 11:45:45AM +0100, Richard Biener wrote:
> The question is, whether a NULL cc_use_loc (find_single_use returning
> NULL) means "there is no use" or it can mean "huh, don't know, maybe
> more than one, maybe I was too stupid to indentify the single use".
> The implementation
On Thu, Mar 07, 2024 at 11:22:12AM +0100, Richard Biener wrote:
> > > > Undo the combination if *cc_use_loc is not COMPARISON_P.
Why, anyway? COMPARISON_P means things like LE. It does not even
include actual RTX COMPARE.
Segher
On Thu, Mar 07, 2024 at 10:55:12AM +0100, Richard Biener wrote:
> On Thu, 7 Mar 2024, Uros Bizjak wrote:
> > This is
> >
> > 3236 /* Just replace the CC reg with a new mode. */
> > 3237 SUBST (XEXP (*cc_use_loc, 0), newpat_dest);
> > 3238 undobuf.other_insn
Hi!
On Mon, Feb 19, 2024 at 04:24:37PM +0530, Ajit Agarwal wrote:
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -518,7 +518,7 @@ or1k*-*-*)
> ;;
> powerpc*-*-*)
> cpu_type=rs6000
> - extra_objs="rs6000-string.o rs6000-p8swap.o rs6000-logue.o"
> +
On Wed, Feb 28, 2024 at 11:58:15AM -0600, Peter Bergner wrote:
> On 2/28/24 8:31 AM, Segher Boessenkool wrote:
> > On Tue, Feb 27, 2024 at 04:50:02PM -0600, Peter Bergner wrote:
> >> So it seems you're not NAKing the use of splat_input_operand, but
> >> just tha
On Tue, Feb 27, 2024 at 04:50:02PM -0600, Peter Bergner wrote:
> On 2/27/24 6:40 AM, Segher Boessenkool wrote:
> > On Tue, Feb 27, 2024 at 02:02:38AM +0530, jeevitha wrote:
> > input_operand allows a lot of things that splat_input_operand does not,
> > not just imm
Hi!
On Tue, Feb 27, 2024 at 02:02:38AM +0530, jeevitha wrote:
> There is no immediate value splatting instruction in Power. Currently, those
> values need to be stored in a register or memory. To address this issue, I
> have updated the predicate for the second operand in vsx_splat to
>
On Tue, Feb 20, 2024 at 06:35:34PM +0800, Kewen.Lin wrote:
> on 2024/2/8 03:58, Michael Meissner wrote:
> $ grep -r "define PROCESSOR_DEFAULT" gcc/config/rs6000/
> gcc/config/rs6000/aix71.h:#define PROCESSOR_DEFAULT PROCESSOR_POWER7
> gcc/config/rs6000/aix71.h:#define PROCESSOR_DEFAULT64
On Thu, Feb 22, 2024 at 07:49:20PM +, Richard Sandiford wrote:
> Thanks for the update. This is still quite hard to review though.
> Sorry to ask for another round, but could you split it up further?
> The ideal thing would be if patches that move code do nothing other
> than move code, and
On Tue, Feb 20, 2024 at 01:49:30PM -0600, Peter Bergner wrote:
> I think this will become less fragile after we fix PR114004 which is
You call it "fragile". I call it the testcase found the exact kind of
bug this testcase was meant to find!
Yes, the test should become quieter when the compiler
On Tue, Feb 20, 2024 at 05:27:07PM +0800, Kewen.Lin wrote:
> > -mcpu=power8 implies -mvsx already.
>
> Yes, but users can specify -mno-vsx in RUNTESTFLAGS, dejagnu
> framework can have different behaviors (options order) for
> different versions, this explicit -mvsx is mainly for the
>
Hi!
On Tue, Jan 16, 2024 at 10:50:01AM +0800, Kewen.Lin wrote:
> As PR109987 and its duplicated bugs show, -mno-power8-vector
> (and -mno-power9-vector) cause some problems and as Segher
> pointed out in [1] they are workaround options, so this patch
> is to remove -m{no,}-power{8,9}-options.
On Fri, Feb 16, 2024 at 11:34:55AM +, Maciej W. Rozycki wrote:
> Not really, in particular because EH unwinding has to be reliable and
> heuristics inherently is not.
Yup. Which is why I did 0359465c703a for rs6000 six years ago (how time
flies!) The commit message for that includes
On Thu, Feb 15, 2024 at 08:41:42PM -0500, Paul Koning wrote:
> > On Feb 15, 2024, at 5:56 PM, Segher Boessenkool
> > wrote:
> >
> > On Thu, Feb 15, 2024 at 07:34:32PM +, Sam James wrote:
> >> I have now started doing this in PR113932.
> >
> &g
On Thu, Feb 15, 2024 at 07:34:32PM +, Sam James wrote:
> I have now started doing this in PR113932.
Thank you!
Segher
On Fri, Jan 05, 2024 at 06:35:37PM -0500, Michael Meissner wrote:
> * config/rs6000/rs6000.opt (-mfuture): New undocumented debug switch.
No. Never ever use a flag that does what -mcpu= should do. We're
still trying to recover from previous such mistakes. Don't add more
please.
> +++
On Wed, Feb 07, 2024 at 05:21:10PM +0800, Kewen.Lin wrote:
> on 2024/2/6 14:01, Michael Meissner wrote:
> > It was more as a separation. The MPCCORE, CELL, PPCA2, and TITAN are rather
> > old processors.
I'll probably remove Titan soonish, btw. We have adjusted code around
it for what, fifteen
On Tue, Feb 06, 2024 at 01:01:52AM -0500, Michael Meissner wrote:
> > Nit: Named as "ISA_FUTURE_MASKS_SERVER" seems more accurate as it's
> > constituted
> > with ISA_3_1_MASKS_**SERVER** ...
>
> Well the _SERVER stuff was due to the power7 days when we still had to support
> the E500 in the
Hi!
On Fri, Jan 05, 2024 at 06:27:05PM -0500, Michael Meissner wrote:
> In the current MMA subsystem for Power10, there are 8 512-bit accumulator
> registers. These accumulators are each tied to sets of 4 FPR registers. When
Four VSX registers -- the FP registers are only a 64 bit part of each
Hi!
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.
But it is not. It is a completely new thing, and much closer to
fwprop than to combine, too.
Could you rename it to something else, please? Something less
On Fri, Dec 29, 2023 at 09:14:52PM -0700, Jeff Law wrote:
> On 12/29/23 10:46, YunQiang Su wrote:
> >When we try to combine RTLs, the result may be very complex,
> >and `rtx_cost` may think that it need lots of costs. But in
> >fact, it may match a pattern in machine descriptions, which
> >may
Hi!
On Wed, Nov 29, 2023 at 02:20:03PM +0100, Uros Bizjak wrote:
> On Wed, Nov 29, 2023 at 1:25 PM Richard Biener
> wrote:
> > On Wed, Nov 29, 2023 at 10:35 AM Uros Bizjak wrote:
> I was assuming that if the CC reg is not used inside the comparison,
> then the mode of CC reg is irrelevant. We
On Tue, Oct 31, 2023 at 08:31:25AM -0700, Carl Love wrote:
> > I just found that actually they have the test coverage, because we
> > have
> >
> > #define __builtin_bcdcmpeq(a,b) __builtin_vec_bcdsub_eq(a,b,0)
> > #define __builtin_bcdcmpgt(a,b) __builtin_vec_bcdsub_gt(a,b,0)
> > #define
Hi!
Please say "rs6000/p8swap:" in the subject, not "swap:" :-)
On Sun, Sep 10, 2023 at 10:58:32PM +0530, Surya Kumari Jangala wrote:
> Another issue with always handling swappable instructions is that it is
> incorrect to do so in webs where loads/stores on quad word aligned
> addresses are
On Fri, Sep 29, 2023 at 02:09:12PM -0400, Michael Meissner wrote:
> * config/rs6000/rs6000.md (UNSPEC_COPYSIGN): Delete.
> (copysign3_fcpsg): Use copysign RTL instead of UNSPEC.
(typo, it is _fcpsgn)
Nice to see unnecessary unspecs going away :-)
Segher
Hi!
On Fri, Jun 30, 2023 at 02:26:35PM -0500, Pat Haugen wrote:
> gcc/
> * config/rs6000/rs6000.cc (rs6000_rtx_costs): Check if disabling
> scalar modulo.
"Check whether the modulo instruction is disabled?"
> * config/rs6000/rs6000.md (mod3, *mod3): Disable.
> (define_expand
On Thu, Sep 07, 2023 at 02:23:00PM +0300, Dan Carpenter wrote:
> On Thu, Sep 07, 2023 at 06:04:09AM -0500, Segher Boessenkool wrote:
> > On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches
> > wrote:
> > > I started to hunt
> > > down all
On Thu, Sep 07, 2023 at 07:22:45AM -0400, Steven Rostedt wrote:
> On Thu, 7 Sep 2023 06:04:09 -0500
> Segher Boessenkool wrote:
> > On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches
> > wrote:
> > No. You should patch your program, instead.
On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches wrote:
> I started to hunt
> down all the Makefile which add a -Werror but there are a lot and
> eventually I got bored and gave up.
I have a patch stack for that, since 2014 or so. I build Linux with
unreleased GCC versions
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 useless .
This patch does that, you mean.
> --- a/gcc/config/rs6000/vsx.md
> +++
On Thu, Jul 06, 2023 at 02:48:19PM -0500, Peter Bergner wrote:
> On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> > On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
> >> --- a/gcc/config/rs6000/rs6000.cc
> >> +++ b/gcc/config/rs6000/rs6000
Hi!
On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> while generating vector pairs of load & store instruction, the src address
> was treated as an altivec type and that type of address is invalid for
Hi!
The patch looks great now, thanks you!
But the commit message needs some work:
First off, the subject, which is a short (50 character max!) summary of
what the patch is about.
Fix power10 fusion and -fstack-protector, PR target/105325
There is absolutely nothing to do with stack protector,
Hi!
On Fri, Jun 16, 2023 at 04:34:12PM +0800, Jiufu Guo wrote:
> +/* Check if value C can be built by 2 instructions: one is 'li', another is
> + rotldi.
> +
> + If so, *SHIFT is set to the shift operand of rotldi(rldicl), and *MASK
> + is set to -1, and return true. Return false
On Thu, Jun 15, 2023 at 03:00:40PM +0800, Jiufu Guo wrote:
> >> This is the existing pattern. It may be read as an action
> >> to clean an unknown-size memory block.
> >
> > Including a size zero memory block, yes. BLKmode was originally to do
> > things like bcopy (before modern names like
On Wed, Jun 14, 2023 at 06:25:10PM +0200, Richard Biener wrote:
> > Form rs6000.md:
> > ; This is to explain that changes to the stack pointer should
> > ; not be moved over loads from or stores to stack memory.
> > (define_insn "stack_tie"
>
> That suggests it’s the hard register value that‘s
Hi!
On Wed, Jun 14, 2023 at 10:04:20AM +0100, Richard Sandiford wrote:
> I'd also understood it to be either. As in, it is a may-clobber
> that can be used for must-clobber. Alternatively: the value stored
> is unpredictable, and can therefore be the same as the current value.
Yes, it is a set
On Wed, Jun 14, 2023 at 09:22:09AM +, Richard Biener wrote:
> How can a clobber be validly dropped?
Same as any other set: if no code executed after it can read whatever is
written. This typically means a stack frame goes away, or simply no
more code is executed *at all* after this.
> For
Hi!
On Wed, Jun 14, 2023 at 09:52:37AM +, Richard Biener wrote:
> I see. So
>
> (parallel
> (unspec stack_tie)
> (clobber (mem:BLK ...)))
Written like this, without a "set", *every* unspec has to be an
unspec_volatile, for the same reason as all inline asms without outputs
always are
Hi!
On Wed, Jun 14, 2023 at 05:26:52PM +0800, Jiufu Guo wrote:
> Richard Biener writes:
> >> 3. "set (mem/c:DI (reg/f:DI 1 1) unspec:DI (const_int 0 [0])
> >> UNSPEC_TIE".
> >>This avoids using BLK on unspec, but using DI.
> >
> > That gives the MEM a size which means we can interpret the
Hi!
On Wed, Jun 14, 2023 at 07:59:04AM +, Richard Biener wrote:
> On Wed, 14 Jun 2023, Jiufu Guo wrote:
> > 3. "set (mem/c:DI (reg/f:DI 1 1) unspec:DI (const_int 0 [0])
> > UNSPEC_TIE".
> >This avoids using BLK on unspec, but using DI.
>
> That gives the MEM a size which means we can
Hi!
On Wed, Jun 14, 2023 at 12:06:29PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> I'm also thinking about other solutions:
> 1. "set (mem/c:BLK (reg/f:DI 1 1) (const_int 0 [0])"
> This is the existing pattern. It may be read as an action
> to clean an
Hi!
On Wed, Jun 14, 2023 at 05:18:15PM +0800, Xi Ruoyao wrote:
> The generic issue here is to fix (not "papering over") the signed
> overflow, we need to perform the addition in a target machine mode. We
> may always use Pmode (IIRC const_anchor was introduced for optimizing
> some constant
Hi!
As I said in a reply to the original patch: not okay. Sorry.
But some comments on this patch:
On Tue, Jun 13, 2023 at 08:23:35PM +0800, Jiufu Guo wrote:
> + && XINT (SET_SRC (set), 1) == UNSPEC_TIE
> + && XVECEXP (SET_SRC (set), 0, 0) == const0_rtx);
This makes it required
Hi!
On Tue, Jun 13, 2023 at 10:15:49AM +0800, Jiufu Guo wrote:
> David Edelsohn writes:
> >
> > This definitely seems to be a better solution.
> >
> > The TARGET_CONST_ANCHOR change should not be part of this patch. Also
> > there is no ChangeLog for the patch.
>
> Thanks a lot for your quick
Hi!
On Sat, Feb 25, 2023 at 03:20:33PM +0530, Ajit Agarwal wrote:
> Here is the patch that uses xxlor instead of fmr where possible.
> Performance results shows that fmr is better in power9 and
> power10 architectures whereas xxlor is better in power7 and
> power 8 architectures. fmr is the only
Hi!
On Wed, Jun 07, 2023 at 04:21:11PM +0800, Jiufu Guo wrote:
> This patch tries to optimize "(X - N * M) / N" to "X / N - M".
> For C code, "/" towards zero (trunc_div), and "X - N * M" maybe
> wrap/overflow/underflow. So, it is valid that "X - N * M" does
> not cross zero and does not
2023-06-06 Segher Boessenkool
* config/rs6000/genfusion.pl: Delete some dead code.
---
gcc/config/rs6000/genfusion.pl | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/rs6000/genfusion.pl b/gcc/config/rs6000/genfusion.pl
index 2851bb7..82e8f86 100755
--- a/gcc/config
;s or "qw" for lists of constants.
2023-06-06 Segher Boessenkool
* config/rs6000/genfusion.pl (gen_ld_cmpi_p10_one): New, rewritten and
split out from...
(gen_ld_cmpi_p10): ... this.
---
gcc/config/rs6000/genfusion.pl | 185 +++-
Hi!
On Mon, Jun 05, 2023 at 12:11:42PM +0530, P Jeevitha wrote:
> PR106907 has few warnings spotted from cppcheck. In that addressing duplicate
> expression issue here. Here the same expression is used twice in logical
> AND(&&) operation which result in same result so removing that.
>
>
On Wed, May 10, 2023 at 11:40:00AM -0400, Michael Meissner wrote:
> 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.
The low two
Hi Mike,
On Wed, May 10, 2023 at 11:38:55AM -0400, Michael Meissner wrote:
> This patch rewrites the gen_ld_cmpi_p10 function in genfusion.pl to be
> clearer.
That is not at all what I asked for, even if I would agree the code is
nicer to read now (I don't).
What I asked for, what is needed,
On Thu, May 25, 2023 at 10:29:47AM -0400, Vladimir Makarov wrote:
>
> On 5/17/23 02:57, liuhongt wrote:
> >r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost
> >calculation when the preferred register class are not known yet.
> >It regressed powerpc PR109610 and PR109858, it looks
Hi Alex,
On Thu, May 25, 2023 at 10:55:37AM -0300, Alexandre Oliva wrote:
> On May 25, 2023, Segher Boessenkool wrote:
> > Fwiw, updating the insn counts blindly like this
>
> ... is a claim that carries a wildly incorrect and insulting underlying
> assumption:
Sorry you f
Hi!
On Thu, May 25, 2023 at 07:05:55AM -0300, Alexandre Oliva wrote:
> On May 25, 2023, "Kewen.Lin" wrote:
> > So both lp64 and ilp32 have the same count, could we merge it and
> > remove the selectors?
>
> We could, but... I thought I wouldn't, since they were different
> before, and they're
Hi!
On Thu, May 18, 2023 at 12:44:28PM +0530, Ajit Agarwal wrote:
> This patch improves code sinking pass to sink statements before call to reduce
> register pressure.
An example would be useful :-)
> * tree-ssa-sink.cc (statement_sink_location): Modifed to
> move statements before
Hi!
On Tue, May 16, 2023 at 11:45:28AM +0530, Ajit Agarwal wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -12455,8 +12455,8 @@ Attempt to remove redundant extension instructions.
> This is especially
> helpful for the x86-64 architecture, which implicitly zero-extends in
On Thu, May 04, 2023 at 01:54:46PM +0800, liuhongt wrote:
> r14-172-g0368d169492017 use NO_REGS instead of GENERAL_REGS in memory cost
> calculation when preferred register class is unkown.
> + /* Costs for NO_REGS are used in cost calculation on the
> +1st pass when the preferred
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.
> Use the YZ constraint for these loads. Handle prefixed loads
Hi!
On Tue, May 02, 2023 at 05:20:49PM +0100, Roger Sayle wrote:
> On 02 May 2023 14:49, Segher Boessenkool wrote:
> Then combine inserts an additional copy:
Combine makes sure a pseudo-to-pseudo move remains. Without that,
combine will seize part of RA's job, and butcher it. It has
On Tue, May 02, 2023 at 10:11:27AM -0400, Paul Koning wrote:
> > On May 2, 2023, at 9:18 AM, Roger Sayle wrote:
> > Yes, see the section -fsplit-wide-types in
> > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>
> Thanks. So I'm wondering why that would be a problem.
>
> The obvious
Hi!
On Tue, May 02, 2023 at 02:18:43PM +0100, Roger Sayle wrote:
> On 02 May 2023 13:40, Paul Koning wrote:
> > > On May 1, 2023, at 7:37 PM, Roger Sayle
> > wrote:
> > > The shiftsi.cc regression on xstormy16 is fixed by adding
> > > -fno-split-wide-types.
> > > In fact, if all the regression
Hi!
On Sat, Apr 22, 2023 at 02:36:20PM +0530, Ajit Agarwal wrote:
> * ree.cc (combline_reaching_defs): Add zero_extend
> using defined abi interfaces.
Typo. Also, please don't wrap lines early. Also, you are missing some
changes in this file in the changelog.
>
Hi!
On Fri, Mar 17, 2023 at 11:39:52AM +0800, Jiufu Guo wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.target/powerpc/pr65421-1.c: New test.
> * gcc.target/powerpc/pr65421.c: New test.
Please name the tests something else? -1.c and -2.c maybe. Or
something more inspired. Just not
Hi!
On Mon, Apr 24, 2023 at 11:46:50AM +0200, Uros Bizjak wrote:
> On Mon, Apr 24, 2023 at 11:19 AM Segher Boessenkool
> wrote:
> > We still need someone to test this on alpha now, years later, and give
> > a final okay, but hearing this is encouraging :-)
>
> Please no
Hi!
On Mon, Apr 24, 2023 at 05:54:02PM +0200, Jakub Jelinek wrote:
> The problem is that the *branch_anddi3_dot define_insn_and_split
> relies on the *rotldi3_mask_dot define_insn_and_split being recognized
> during splitting. The rs6000_is_valid_rotate_dot_mask function checks whether
> the
Hi!
On Mon, Mar 27, 2023 at 04:09:39PM +0800, Kewen.Lin wrote:
> As PR109069 shows, commit r12-6537-g080a06fcb076b3 which
> introduces define_insn_and_split sldoi_to_mov adopts
> easy_vector_constant for const vector of interest, but it's
> wrong since predicate easy_vector_constant doesn't
On Mon, Apr 24, 2023 at 10:19:23AM +0200, Richard Biener wrote:
> On Sun, Apr 23, 2023 at 6:48 PM Segher Boessenkool
> wrote:
> >
> > This minimal patch enables LRA for all targets. It does not clean up
> > the target code, nor does it do anything to generic code: it jus
1 - 100 of 6031 matches
Mail list logo
