Hi!
On Thu, Feb 10, 2022 at 04:28:02PM -0600, Bill Schmidt wrote:
> On 2/10/22 4:11 PM, Segher Boessenkool wrote:
> >> No, trunk has this, for example:
> >>
> >> const signed int __builtin_altivec_vclzlsbb_v16qi (vsc);
> >> VCLZLSBB_V16QI vctzlsbb
Hi!
On Fri, Jan 28, 2022 at 10:47:06PM -0500, Michael Meissner wrote:
> Use correct names for __ibm128 if long double is IEEE 128-bit.
>
> If you are on a PowerPC system where the default long double is IEEE
> 128-bit, GCC will use the wrong names for some of the conversion functions
> for the __
Hi!
On Wed, Feb 09, 2022 at 10:43:17AM +0800, HAO CHEN GUI wrote:
> This patch removes TImode from mode iterator BOOL_128. Thus, bool
> operations (AND, IOR, XOR, NOT)
> on TImode will be split to the relevant operations on word mode during expand
> (in optabs.c).
But we also want to allow TI
On Tue, Feb 15, 2022 at 11:01:03AM +0800, HAO CHEN GUI wrote:
Hi!
> On 15/2/2022 上午 5:36, Segher Boessenkool wrote:
> > On Wed, Feb 09, 2022 at 10:43:17AM +0800, HAO CHEN GUI wrote:
> > All that are arguments for expanding to split form, not for removing
> > TImode from t
On Tue, Feb 15, 2022 at 12:49:41PM -0500, Michael Meissner wrote:
> Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__.
>
> Define the sizes of the PowerPC specific types __float128 and __ibm128 if
> those
> types are enabled.
This is very silly of course, both of these are 16 bytes. Abusing this
Hi!
On Tue, Feb 15, 2022 at 01:03:09PM -0600, Peter Bergner wrote:
> The HTM tbegin. instruction can fail intermittently due to many reasons.
Just a few really. But, if the transaction fails it will appear as if
the tbegin. had an error as well, is that what you are seeing?
> This can lead to t
On Tue, Feb 15, 2022 at 03:18:30PM -0500, Michael Meissner wrote:
> On Tue, Feb 15, 2022 at 01:45:06PM -0600, Segher Boessenkool wrote:
> > On Tue, Feb 15, 2022 at 12:49:41PM -0500, Michael Meissner wrote:
> > > Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__.
> > >
&g
On Tue, Feb 15, 2022 at 04:59:45PM -0600, Peter Bergner wrote:
> > That is the way any HTM code should be written in the first place
> > (except for rollback-only transactions, but let's not go there --
> > besides, it is normal for those to fail as well, and there needs to be a
> > fallback there
On Tue, Feb 15, 2022 at 06:05:06PM -0500, Michael Meissner wrote:
> On Tue, Feb 15, 2022 at 04:05:11PM -0600, Segher Boessenkool wrote:
> > On all older compilers these macros will not be defined, but the types
> > often are. If you are willing to not support older compilers prop
Hi!
On Wed, Feb 16, 2022 at 09:53:34AM +0100, Jakub Jelinek wrote:
> On the following testcase on aarch64-linux, we behave differently
> with -g and -g0.
[ huge snip ]
> The following patch fixes that by instead ignoring debug insns during the
> searching. We can still check BLOCK_FOR_INSN (ins
On Wed, Feb 16, 2022 at 11:55:23AM +0100, Jakub Jelinek wrote:
> On Wed, Feb 16, 2022 at 04:44:58AM -0600, Segher Boessenkool wrote:
> > About half of the similar loops in combine.c are still broken this way,
> > from a quick sampling :-(
>
> Looking for just NONDEBUG_IN
Hi!
On Wed, Feb 16, 2022 at 08:11:17PM +0100, Robin Dapp wrote:
> since r12-6747-gaa8cfe785953a0 ifcvt not only passes real comparisons
> but also "cc comparisons" (i.e. the representation of the result of a
> comparison) to the backend. rs6000_emit_int_cmove () is not prepared to
> handle this.
Hi!
On Wed, Feb 16, 2022 at 06:03:53PM -0500, Michael Meissner wrote:
> [PATCH, V3] Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__.
>
> Define the sizes of the PowerPC specific types __float128 and __ibm128 if
> those
> types are enabled.
>
> This patch will define __SIZEOF_IBM128__ and __SIZ
On Wed, Feb 16, 2022 at 09:05:05PM -0600, Paul A. Clarke wrote:
> Properly prefix (with "__") all local variables in shipped headers for x86
> compatibility intrinsics implementations. This avoids possible problems with
> usages like:
> ```
> #define result X
> #include
> ```
>
> 2021-02-16 Pa
Hi!
On Fri, Jan 28, 2022 at 12:03:09PM -0600, Pat Haugen wrote:
> Mark Power10 fusion option undocumented and remove sub-options.
> gcc/
> * config/rs6000/rs6000.opt (mpower10-fusion): Mark Undocumented.
> (mpower10-fusion-ld-cmpi, mpower10-fusion-2logical,
> mpower10-fusion-log
Hi!
First, you need to adjust after Robin's patch, and retest.
On Thu, Feb 17, 2022 at 01:56:04PM -0500, Michael Meissner wrote:
> Don't do int cmoves for IEEE comparisons, PR target/104256.
> Unfortunately there are some conditions like UNLE that can't easily be
> reversed
> due to NaNs.
What
Hi Jiu Fu,
On Tue, Feb 22, 2022 at 02:53:13PM +0800, Jiufu Guo wrote:
> static bool
> rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
> {
> - if (GET_CODE (x) == HIGH
> - && GET_CODE (XEXP (x, 0)) == UNSPEC)
> + if (GET_CODE (x) == HIGH)
> return true;
Thi
Hi!
On Mon, Feb 21, 2022 at 03:17:45PM -0600, Paul A. Clarke wrote:
> Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
> longer required.
>
> 2021-02-21 Paul A. Clarke
>
> gcc/testsuite
> * g++.dg/ext/altivec-1.C: Move to g++.target/powerpc, adjust dg
>
On Mon, Feb 21, 2022 at 03:17:44PM -0600, Paul A. Clarke wrote:
> Some tests in g++.dg are target-specific for powerpc. Move those to
> g++.target/powerpc. Update the DejaGnu directives as needed, since
> the target restriction is perhaps no longer needed when residing in the
> target-specific powe
On Mon, Feb 21, 2022 at 03:17:46PM -0600, Paul A. Clarke wrote:
> Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
> longer required.
>
> 2021-02-21 Paul A. Clarke
>
> gcc/testsuite
> * g++.dg/pr65240.h: Move to g++.target/powerpc.
> * g++.dg/pr93974.C
On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote:
> I'm assuming we're always dealing with
>
> (set (reg:MODE ..) )
>
> here and CSE is not substituting into random places of an
> instruction(?). I don't know what 'rtx_cost' should evaluate
> to for a constant, if it should impli
On Wed, Feb 23, 2022 at 07:32:55PM +0800, guojiufu wrote:
> >We already have TARGET_INSN_COST which you could ask for a cost.
> >Like if we'd have a single_set then just temporarily substitute
> >the RHS with the candidate and cost the insns and compare against
> >the original insn cost. So why ex
On Thu, Feb 10, 2022 at 04:17:00PM -0600, Pat Haugen wrote:
> Per Alan's comment in the bugzilla, fix attr-retain-* tescases for 32-bit
> PowerPC.
> --- a/gcc/testsuite/gcc.c-torture/compile/attr-retain-1.c
> +++ b/gcc/testsuite/gcc.c-torture/compile/attr-retain-1.c
> @@ -1,4 +1,5 @@
> /* { dg-d
Hi Iain,
On Thu, Feb 24, 2022 at 04:02:30PM +, Iain Sandoe wrote:
> > On 22 Feb 2022, at 14:44, Vladimir Makarov wrote:
> > On 2022-02-20 12:34, Iain Sandoe wrote:
> >>
> >> ^^^ this is mostly for my education - the stuff below is a potential
> >> solution to leaving lra-constraints unchang
Hi!
On Thu, Feb 24, 2022 at 03:48:54PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > That is the problem yes. You need insns to call insn_cost on. You can
> > look in combine.c:combine_validate_cost to see how this can be done; but
> > you need to have some co
On Thu, Feb 24, 2022 at 09:50:28AM +0100, Richard Biener wrote:
> On Thu, 24 Feb 2022, Jiufu Guo wrote:
> > And another thing as Segher pointed out, CSE is doing too
> > much work. It may be ok to separate the constant handling
> > logic from CSE.
>
> Not sure - CSE just is value numbering, I don
Hi!
On Tue, Nov 16, 2021 at 02:26:22PM -0600, Bill Schmidt wrote:
> Hi! I recently submitted [1] to make adjustments to test cases for the new
> builtins
> support, mostly due to error messages changing for consistency. Thanks for
> the
> previous review. I've reviewed the reasons for the cha
On Wed, Nov 17, 2021 at 07:52:38AM -0600, Bill Schmidt wrote:
> >> - For int_128bit-runnable.c, I chose not to do gimple folding on the
> >> 128-bit
> >>comparison operations in the new implementation, because doing so
> >> results in
> >>bad code that splits things into two 64-bit value
On Wed, Nov 17, 2021 at 11:45:02AM -0600, Paul A. Clarke wrote:
> I guess I'm being pedantic. "requires -mcpu=power8 and -mvsx" is not
> accurate from a user's point a view, as "-mcpu=power8" is sufficient,
> since "-mvsx" is enabled when "-mcpu=power8" is specified.
To be really pedantic, -mcpu=
On Tue, Nov 16, 2021 at 11:12:35AM -0600, Bill Schmidt wrote:
> Hi! During a previous patch review, Segher asked that I provide better
> messages when builtins are unavailable because they require both a minimum
> CPU and the enablement of VSX instructions. This patch does just that.
>
> Bootstr
On Wed, Nov 17, 2021 at 02:58:54PM -0600, Bill Schmidt wrote:
> Hi! This patch is broken out of the previous patch for all the builtins test
> suite adjustments. Here we have some slight changes in error messages due to
> how the internals have changed between the old and new builtins methods.
>
On Thu, Nov 18, 2021 at 10:09:53AM -0600, Bill Schmidt wrote:
> Hi! This patch is broken out from the test case patch for the new builtins
> support.
>
> The old builtins code performs gimple folding on 128-bit compares. This
> results in correct but very inefficient code. (I suspect we may be
Hi!
On Thu, Nov 18, 2021 at 01:45:30PM +0100, Martin Liška wrote:
> @Segher: PING
This is the first time I recieved this.
Please resend, without line wrapping (format=flawed).
Segher
On Wed, Nov 17, 2021 at 10:43:58PM +, Joseph Myers wrote:
> On Wed, 17 Nov 2021, Prathamesh Kulkarni via Gcc-patches wrote:
> > More generally, would it be a good idea to provide attributes for
> > mod/ref anaylsis ?
> > So sth like:
> > void foo(void) __attribute__((modifies(errno)));
> > whic
Hi!
On Wed, Nov 17, 2021 at 05:06:05PM -0600, Bill Schmidt wrote:
> > I don't like that at all. The user didn't write the _vsx thing, and it
> > isn't documented either (neither is the _vec one, but that is a separate
> > issue, specific to this builtin).
>
> I feel like I haven't explained this
On Thu, Nov 18, 2021 at 07:32:27AM -0600, Bill Schmidt wrote:
> >>> error: '__builtin_vsx_scalar_extract_sig' requires the '-mcpu=power9'
> >>> option and either the '-m64' or '-mpowerpc64' option
> >>> note: builtin '__builtin_vec_scalar_extract_sig' requires builtin
> >>> '__builtin_vsx_sca
On Thu, Nov 18, 2021 at 07:42:34AM -0600, Bill Schmidt wrote:
> gcc/testsuite/
> * gcc.target/powerpc/byte-in-set-2.c: Adjust error message.
"Adjust expected error message" maybe?
Okay for trunk. Thanks!
Segher
On Thu, Nov 18, 2021 at 03:30:48PM -0600, Bill Schmidt wrote:
>
> On 11/18/21 3:16 PM, Segher Boessenkool wrote:
> > Hi!
> >
> > On Wed, Nov 17, 2021 at 05:06:05PM -0600, Bill Schmidt wrote:
> >>> I don't like that at all. The user didn't write
On Fri, Nov 19, 2021 at 12:32:09PM +0100, Martin Liška wrote:
> On 11/18/21 19:59, Segher Boessenkool wrote:
> >Please resend, without line wrapping (format=flawed).
>
> Done in the original [v4] email, see here:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/5842
On Fri, Nov 19, 2021 at 01:31:21PM +0100, Martin Liška wrote:
> All right, so I can't send an email from my local machine and git imap-send
> does not work as it goes through Thunderbird.
Hrm, painful (for you). You should figure out how you can do the basics
of the patch-based workflow that we a
Hi!
On Fri, Oct 22, 2021 at 12:28:49PM -0500, Paul A. Clarke wrote:
> Power9 ISA added `vabsdub` instruction which is realized in the
> `vec_absd` instrinsic.
>
> Use `vec_absd` for `_mm_sad_epu8` compatibility intrinsic, when
> `_ARCH_PWR9`.
>
> Also, the realization of `vec_sum2s` on little-en
On Thu, Oct 21, 2021 at 12:22:12PM -0500, Paul A. Clarke wrote:
> Power10 ISA added `vextract*` instructions which are realized in the
> `vec_extractm` instrinsic.
>
> Use `vec_extractm` for `_mm_movemask_ps`, `_mm_movemask_pd`, and
> `_mm_movemask_epi8` compatibility intrinsics, when `_ARCH_PWR10
On Thu, Nov 18, 2021 at 06:45:42PM -0500, David Malcolm wrote:
> On Thu, 2021-11-18 at 14:08 -0600, Segher Boessenkool wrote:
> > We need some way to describe these things in Gimple and RTL as well,
> > and not just on function calls: also on other expressions. Adding
> > att
Hi!
On Tue, Nov 16, 2021 at 11:06:55AM -0600, Bill Schmidt via Gcc-patches wrote:
> gcc/
> * config/rs6000/rs6000-builtin-new.def: Add power6-64 stanza.
> Move CMPB to power6-64 stanza.
Don't break lines early please.
> * config/rs6000/rs6000-call.c (rs6000_invalid_new_builtin)
On Wed, Nov 24, 2021 at 05:22:57PM -0300, Raoni Fassina Firmino wrote:
> Hi Joseph,
>
> Thanks for the detailed review and explanations.
>From me as well :-)
> On Mon, Oct 18, 2021 at 03:54:53PM +, Joseph Myers wrote:
> > However, it's better to get things right automatically without needing
Hi!
On Wed, Nov 24, 2021 at 08:48:47PM -0300, Raoni Fassina Firmino wrote:
> gcc/ChangeLog:
> * builtins.c (expand_builtin_fegetround): New function.
> (expand_builtin_feclear_feraise_except): New function.
> (expand_builtin): Add cases for BUILT_IN_FEGETROUND,
> BU
Hi!
On Thu, Nov 25, 2021 at 11:20:57AM +0800, Kewen.Lin wrote:
> This patch is to add a test case similar to the one in i386
> to add testing coverage for 510.parest_r hotspots.
> gcc/testsuite/ChangeLog:
> * gcc.target/powerpc/vect-gather-1.c: New test.
This is okay for trunk. Thanks!
Hi!
On Tue, Nov 23, 2021 at 01:14:05PM -0600, Bill Schmidt wrote:
> Paul Clarke pointed out to me that I had wrongly used a compile-time check
> instead of a run-time check in this executable test. This patch fixes
> that. I also fixed a typo in a string that caught my eye.
>
> Tested on powerp
Hi!
On Tue, Nov 23, 2021 at 12:40:45PM -0600, Bill Schmidt wrote:
> When a built-in function required by an overloaded function name is not
> currently enabled, the diagnostic message is not as clear as it should be.
> Saying that one built-in "requires" another is somewhat misleading. It
Hi!
On Wed, Sep 01, 2021 at 02:55:51PM +0800, Kewen.Lin wrote:
> This patch is to fix the inconsistent behaviors for non-LTO mode
> and LTO mode. As Martin pointed out, currently the function
> rs6000_can_inline_p simply makes it inlinable if callee_tree is
> NULL, but it's wrong, we should use t
Hi!
On Tue, Sep 28, 2021 at 04:16:04PM +0800, Kewen.Lin wrote:
> This patch follows the discussions here[1][2], where Segher
> pointed out the existing way to guard the extra penalized
> cost for strided/elementwise loads with a magic bound does
> not scale.
>
> The way with nunits * stmt_cost ca
Hi!
On Fri, Jun 11, 2021 at 09:16:21PM +0800, Kewen.Lin wrote:
> >> +/* Should pick up the lowest luid if the references
> >> + are in the same block. */
> >> +if (label_tick == rsp->last_set_table_tick
> >> +&& rsp->last_set_table_luid > insn_luid)
> >> +
Hi!
On Mon, Oct 11, 2021 at 02:30:42PM +0800, Kewen.Lin wrote:
> > If we do need a band-aid for 10 and 11 (and we do as far as I can see),
> > I'd like to see one for just MMA there, and let all other badness fade
> > into history. Unless you can convince me (in the patch / commit
> > message) th
Hi!
On Tue, Sep 28, 2021 at 04:13:40PM +0800, Kewen.Lin wrote:
> PR target/102347
> * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin
> mask check.
(Don't wrap lines early please).
Okay for trunk and all backports. Thanks!
Segher
Hi!
On Tue, Nov 30, 2021 at 04:46:34PM +0800, HAO CHEN GUI wrote:
> This patch modifies the combine pattern with a helper -
> change_pseudo_and_mask when recog fails. The helper converts a single pseudo
> to the pseudo and with a mask if the outer operator is IOR/XOR/PLUS and the
> inner op
Hi!
On Tue, Nov 30, 2021 at 01:05:48PM +0800, Kewen.Lin wrote:
> on 2021/11/30 上午6:06, Segher Boessenkool wrote:
> > On Tue, Sep 28, 2021 at 04:16:04PM +0800, Kewen.Lin wrote:
> >> unsigned adjusted_cost = (nunits == 2) ? 2 : 1;
> >> unsigned extra_co
Hi!
On Wed, Dec 01, 2021 at 09:29:42AM -0600, Bill Schmidt wrote:
> Recently Kewen fixed a problem in the old builtins support where
> rs6000_builtin_decl prematurely indicated that a target builtin is
> unavailable. This also needs to be done for the new builtins support, but in
> this case we h
On Tue, Nov 16, 2021 at 12:56:52PM -0600, Bill Schmidt wrote:
> Hi! I previously posted [1] to correct some problems with the new builtins
> support targeting 32-bit code gen. Based on the discussion, I've made some
> adjustments and would like to submit this for consideration.
>
> We eventually
On Thu, Nov 18, 2021 at 03:59:41PM -0600, Bill Schmidt wrote:
> On 11/18/21 3:32 PM, Segher Boessenkool wrote:
> > On Thu, Nov 18, 2021 at 03:30:48PM -0600, Bill Schmidt wrote:
> >> On 11/18/21 3:16 PM, Segher Boessenkool wrote:
> >>> On Wed, Nov 17, 2021 at 05:06:
On Wed, Nov 17, 2021 at 02:58:54PM -0600, Bill Schmidt wrote:
> Hi! This patch is broken out of the previous patch for all the builtins test
> suite adjustments. Here we have some slight changes in error messages due to
> how the internals have changed between the old and new builtins methods.
>
On Thu, Nov 18, 2021 at 07:47:38AM -0600, Bill Schmidt wrote:
> Hi! This patch is broken out from the patch with test suite changes for the
> new builtins support.
>
> With the old builtins support, cmpb-2.c produces:
> warning: implicit declaration of function '__builtin_cmpb; did you mean
>
On Thu, Nov 18, 2021 at 10:15:21AM -0600, Bill Schmidt wrote:
> Hi! This patch is broken out from the test case patch for the new
> builtins support.
>
> One advantage of the new builtins support is uniform error messages for
> arguments with restricted values. Previously this was done in many p
On Thu, Nov 18, 2021 at 10:18:06AM -0600, Bill Schmidt wrote:
> Hi! This patch is broken out from the test suite patch for the new
> builtins support. This one is just a minor adjustment for the error
> message wording.
>
> Tested on powerpc64le-linux-gnu and powerpc64-linux-gnu (-m32/-m64)
> wi
On Thu, Nov 18, 2021 at 10:36:52AM -0600, Bill Schmidt wrote:
> Hi! This is the last patch broken out of the previous test suite patch
> for the new builtins support.
Whew :-)
> One advantage of the new builtins support is uniform error messages for
> arguments with restricted values. Previousl
On Wed, Dec 01, 2021 at 04:42:19PM -0600, Bill Schmidt wrote:
> On 12/1/21 4:29 PM, Segher Boessenkool wrote:
> > On Thu, Nov 18, 2021 at 10:15:21AM -0600, Bill Schmidt wrote:
> >> All error messages are now one of the following:
> >> "argument %d m
On Thu, Dec 02, 2021 at 10:43:24AM -0600, Bill Schmidt wrote:
> The new built-in infrastructure is now enabled!
Congratulations, and thanks for all the work!
Segher
Hi!
On Thu, Nov 11, 2021 at 04:12:08PM -0600, Peter Bergner wrote:
> This patch adds a new effective-target function that tests whether
> it is safe to emit the ROP-protect instructions and updates the
> ROP test cases to use it.
>
> Segher, as we discussed offline, this uses the double [] which
Hi!
On Thu, Dec 02, 2021 at 04:53:18PM -0600, Bill Schmidt wrote:
> I discovered this bug while working on patches to remove the old built-ins
> infrastructure. I missed a spot in converting from the rs6000_builtins enum
> to
> the rs6000_gen_builtins enum. This fixes it. The fix is technicall
On Fri, Dec 03, 2021 at 11:46:53AM +0800, Kewen.Lin wrote:
> >> This patch is to fix the inconsistent behaviors for non-LTO mode
> >> and LTO mode. As Martin pointed out, currently the function
> >> rs6000_can_inline_p simply makes it inlinable if callee_tree is
> >> NULL, but it's wrong, we shoul
On Mon, Dec 06, 2021 at 11:12:00AM -0700, Martin Sebor wrote:
> On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
> >Approach 1: Custom Address Spaces
> >=
> >
> >GCC's C frontend supports target-specific address spaces; see:
> > https://gcc.gnu.org/onlined
Hi!
On Mon, Dec 06, 2021 at 02:49:03PM -0600, Bill Schmidt wrote:
> To allow for a sane switch-over from the old built-in infrastructure to the
> new, both sets of code have co-existed, with the enabled one under the control
> of the boolean variable new_builtins_are_live. As a first step in remo
Hi!
On Wed, Dec 08, 2021 at 07:06:30PM -0500, David Malcolm wrote:
> On Mon, 2021-12-06 at 13:40 -0600, Segher Boessenkool wrote:
> > Named address spaces are completely target-specific. Defining them
> > with
> > a pragma like this does not allow you to set the pointer
On Thu, Dec 09, 2021 at 09:42:04AM -0700, Martin Sebor wrote:
> On 12/6/21 12:40 PM, Segher Boessenkool wrote:
> >Named address spaces are completely target-specific.
>
> My understanding of these kernel/user address spaces that David
> is adding for the benefit of the an
This small patch changes everything that checks targetm.lra_p behave as
if it returned true.
It has no effect on any primary or secondary target. It also is fine
for nds32 and for nios2, and it works fine for microblaze (which used
old reload before), resulting in smaller code.
I have patches to
On Fri, Oct 14, 2022 at 12:36:47AM +, Koning, Paul wrote:
> I guess I'll have to look harder to see if it's possible to make LRA handle
> CISC addressing modes like memory indirect, autoincrement, autodecrement, and
> others that the old reload handles at least somewhat. Ideally LRA should d
On Fri, Oct 14, 2022 at 03:20:40PM +0900, Takayuki 'January June' Suwa wrote:
> On 2022/10/14 8:56, Segher Boessenkool wrote:
> > And finally, xtensa does
> > /home/segher/src/gcc/libgcc/libgcc2.c:840:1: error: insn does not satisfy
> > its constraints:
> >
Hi!
On Thu, Oct 13, 2022 at 10:47:20PM -0600, Jeff Law wrote:
> On 10/13/22 17:56, Segher Boessenkool wrote:
> >h8300 fails during GCC build:
> >/home/segher/src/gcc/libgcc/unwind.inc: In function
> >'_Unwind_SjLj_RaiseException':
> >/home/segher/src/gcc/libg
On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote:
> >LRA only ever generates insns that pass recog. The backend allows this
> >define_insn, requiring it to be split (it returns template "#"), but
> >then somehow it doesn't match in any split pass?
>
> Nope. The elimination code will just
On Fri, Oct 14, 2022 at 07:58:39PM +, Koning, Paul wrote:
> > On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches
> > wrote:
> > On 10/14/22 11:35, Segher Boessenkool wrote:
> >> On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote:
> >>>> LRA
Hi!
Everything Ke Wen said. Some more commments / hints:
On Mon, Sep 19, 2022 at 11:05:17AM -0500, will schmidt wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/predefine_p7-novsx.c
> @@ -0,0 +1,9 @@
> +/* { dg-do preprocess } */
> +/* Test whether the ARCH_PWR7 and ARCH_PWR8 defi
On Mon, Sep 19, 2022 at 11:13:20AM -0500, will schmidt wrote:
> The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
> and can be disabled by dependent options when it should not be.
> This manifests in the issue seen in PR101865 where -mno-vsx
> mistakenly disables _ARCH_PWR8.
> This cha
Hi!
On Tue, Oct 18, 2022 at 10:17:30AM -0500, will schmidt wrote:
> On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote:
> > It did not happen in GCC 9 obviously. Do you want to take a
> > shot? It
> > doesn't have to be all at once, it's probably best if
On Fri, Oct 14, 2022 at 04:34:04PM +0800, Haochen Jiang wrote:
> Sorry for the previous cover-letter stucking and disturbance and this
> is the right cover letter.
Hi!
Nothing in this cover letter tells me why you sent it to me? Maybe you
shouldn't have at all, just one patch touches Power code,
On Fri, Oct 14, 2022 at 04:34:05PM +0800, Haochen Jiang wrote:
> * config/s390/s390.cc (s390_expand_cpymem): Generate fourth parameter
> for
(Many too long lines here, this is the first one. Changelog lines are
max. 80 positions; a tab is eight).
> + /* Argument 3 must be either zero or
On Wed, Oct 19, 2022 at 10:14:28AM -0700, Andrew Pinski wrote:
> Do the testcases really need to be changed rather than adding new testcases?
> Usually it is better if the testcases not change unless really needed
> to be. That is do these testcases pass without being changed? If not
> this seems n
On Thu, Oct 20, 2022 at 01:44:15AM +, Jiang, Haochen wrote:
> Maybe the testcase change cause some misunderstanding and concern.
>
> Actually, the patch did not disrupt the previous builtins, as the
> builtin_prefetch
> uses vargs. I set the default value of the new parameter as data prefetch
On Thu, Oct 20, 2022 at 11:12:01AM +0800, Hongtao Liu wrote:
> On Thu, Oct 20, 2022 at 9:39 AM Hongtao Liu wrote:
> > On Thu, Oct 20, 2022 at 5:08 AM Segher Boessenkool
> > > Please use a separate pattern for this, and leave prefetch to mean data
> > > prefetch, as doc
On Thu, Oct 20, 2022 at 07:34:13AM +, Jiang, Haochen wrote:
> > > + /* Argument 3 must be either zero or one. */
> > > + if (INTVAL (op3) != 0 && INTVAL (op3) != 1)
> > > +{
> > > + warning (0, "invalid fourth argument to %<__builtin_prefetch%>;"
> > > + " using one");
> >
> > "usi
Hi!
On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches wrote:
> The name nonzero_bits is confusing. We're not tracking nonzero bits.
> We're tracking known-zero bits, or at the worst we're tracking "maye
> nonzero bits". But really, the only thing we're sure about in the
>
On Fri, Oct 21, 2022 at 06:51:17PM +0200, Jakub Jelinek wrote:
> On Fri, Oct 21, 2022 at 11:45:33AM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches
> > wrote:
> > > * asan.cc (handle_builtin_alloca): Rename
On Fri, Oct 21, 2022 at 06:54:32PM +0200, Jakub Jelinek wrote:
> On Fri, Oct 21, 2022 at 06:51:19PM +0200, Jakub Jelinek wrote:
> > Agreed.
> >
> > I think maybe_nonzero_bits would be fine.
>
> Or yet another option is to change what we track and instead of
> having just one bitmask have 2 as tre
On Fri, Oct 21, 2022 at 11:17:39AM +0100, Richard Earnshaw wrote:
> On 20/10/2022 18:37, Andrew Pinski via Gcc-patches wrote:
> >On aarch64 (armv8), it is actually the same instruction: PRFM. It
> >might be the only one which is that way though.
> >It even allows to specify the level for the instru
On Mon, Oct 24, 2022 at 11:00:26AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Thu, Oct 20, 2022 at 07:34:13AM +, Jiang, Haochen wrote:
> >> > > + /* Argument 3 must be either zero or one. */
> >> > > + if
Hi!
On Mon, Oct 24, 2022 at 11:14:20AM +0800, HAO CHEN GUI wrote:
> This patch implements V8HI byte reverse on Power8 by vector rotation.
Please put *byte* reverse as the commit subject as well?
> It should be effecient than orignial vector permute. The patch comes from
> Xionghu's comments in
This is in preparation for adding CCFP, and maybe CCEQ, and whatever
other CC mode we may want later. CCANY is used for CC mode consumers
that actually can take any of the four CR field bits.
Tested on p7 and p9; committing,
Segher
2022-10-25 Segher Boessenkool
* config/rs6000
On Wed, Oct 26, 2022 at 11:58:57AM -0700, H.J. Lu via Gcc-patches wrote:
> In i386.md, neg patterns which set MODE_CC register like
>
> (set (reg:CCC FLAGS_REG)
> (ne:CCC (match_operand:SWI48 1 "general_reg_operand") (const_int 0)))
>
> can lead to errors when operand 1 is a constant value.
Hi!
On Fri, Oct 28, 2022 at 10:35:03AM +0200, Eric Botcazou via Gcc-patches wrote:
> > (set (reg:SI 93)
> > (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0]
> >
> > as
> >
> > (set (reg:SI 93)
> > (neg:SI (ltu:SI (const_int 1) (const_int 0 [0]
> >
> > which leads to incorre
Hi!
On Mon, Oct 31, 2022 at 10:42:35AM +0800, Jiufu Guo wrote:
> #define FN 4
> typedef struct { double a[FN]; } A;
>
> A foo (const A *a) { return *a; }
> A bar (const A a) { return a; }
> ///
>
> If FN<=2; the size of "A" fits into TImode, then this code can be optimized
> (by subreg/cse/
On Mon, Oct 31, 2022 at 04:13:38PM -0600, Jeff Law wrote:
> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote:
> >We know that for struct variable assignment, memory copy may be used.
> >And for memcpy, we may load and store more bytes as possible at one time.
> >While it may be not best here:
>
On Fri, Oct 28, 2022 at 11:55:35PM +0200, Eric Botcazou wrote:
> > You mean in CCV? That works yes, but only because (or if) the setter
> > and getter of the CC reg both use CCV (so never use any other flag at
> > the same time; CCV has an empty intersection with all other CC modes).
>
> We're ta
601 - 700 of 6130 matches
Mail list logo
