Re: [PATCH v1] RISC-V: Fix one bug for floating-point static frm

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-07-04 13:50 To: gcc-patches CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Fix one bug for floating-point static frm From: Pan Li This patch would like to fix one bug to align below

[PATCH v1] RISC-V: Fix one bug for floating-point static frm

From: Pan Li This patch would like to fix one bug to align below items of spec. 1. By default, the RVV floating-point will take dyn mode. 2. DYN is invalid in FRM register for RVV floating-point. When mode switching the function entry and exit, it will take DYN as the frm mode. Signed-off-by:

Re: [PATCH V4 1/4] rs6000: build constant via li;rotldi

Hi Jeff, on 2023/7/4 10:18, Jiufu Guo via Gcc-patches wrote: > Hi, > > If a constant is possible to be rotated to/from a positive or negative > value from "li", then "li;rotldi" can be used to build the constant. > > Compare with the previous version: >

RE: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

Hi Robin, Just revert this patch, it reports some weird illegal instr, I may need more time for this. Pan -Original Message- From: Li, Pan2 Sent: Monday, July 3, 2023 11:00 PM To: Robin Dapp ; juzhe.zh...@rivai.ai; gcc-patches Cc: jeffreyalaw ; Wang, Yanzhang ; kito.cheng Subject:

RE: [PATCH V7] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

Committed as both the bootstrap and regression tests passed, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Sandiford via Gcc-patches Sent: Monday, July 3, 2023 9:50 PM To: juzhe.zh...@rivai.ai Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de Subject: Re:

[PATCH V2] i386: Inline function with default arch/tune to caller

Hi, For function with different target attributes, current logic rejects to inline the callee when any arch or tune is mismatched. Relax the condition to allow callee with default arch/tune to be inlined. Boostrapped/regtested on x86-64-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: *

ping^^^^: [PATCH V2] rs6000: Enhance lowpart/highpart DI->SF by mtvsrws/mtvsrd

Hi, Gentle ping ... Jiufu Guo via Gcc-patches writes: > Gentle ping... > > Jiufu Guo via Gcc-patches writes: > >> Gentle ping... >> >> Jiufu Guo via Gcc-patches writes: >> >>> Hi >>> >>> I would like to ping this patch for stage1: >>>

[PATCH] Break false dependence for vpternlog by inserting vpxor.

vpternlog is also used for optimization which doesn't need any valid input operand, in that case, the destination is used as input in the instruction and that creates a false dependence. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ready to push to trunk. gcc/ChangeLog: PR

RE: [VSETVL PASS] RISC-V: Optimize local AVL propagation

Committed, thanks Kito. Pan -Original Message- From: Gcc-patches On Behalf Of Kito Cheng via Gcc-patches Sent: Tuesday, July 4, 2023 10:20 AM To: Robin Dapp Cc: Juzhe-Zhong ; gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; pal...@dabbelt.com; pal...@rivosinc.com;

Re: [PATCH ver 3] rs6000: Update the vsx-vector-6.* tests.

Hi Carl, on 2023/6/30 05:36, Carl Love wrote: > GCC maintainers: > > Ver 3. Added __attribute__ ((noipa)) to the test files. Changed some > of the scan-assembler-times checks to cover multiple similar > instructions. Change the function check macro to a macro to generate a > function to do

Re: [VSETVL PASS] RISC-V: Optimize local AVL propagation

LGTM On Mon, Jul 3, 2023 at 8:47 PM Robin Dapp wrote: > > LGTM. > > Regards > Robin >

[PATCH V4 1/4] rs6000: build constant via li;rotldi

Hi, If a constant is possible to be rotated to/from a positive or negative value from "li", then "li;rotldi" can be used to build the constant. Compare with the previous version: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621961.html This patch just did minor changes to the style and

Re: [PATCH] rs6000: Update the vsx-vector-6.* tests.

Hi Carl, on 2023/7/3 23:57, Carl Love wrote: > Kewen: > > On Fri, 2023-06-30 at 15:20 -0700, Carl Love wrote: >> Segher never liked the above way of looking at the assembly. He >> prefers: >> gcc -S -g -mcpu=power8 -o vsx-vector-6-func-2lop.s vsx-vector-6- >> func- >> 2lop.c >> >> grep

[committed] CRIS: Replace unspec CRIS_UNSPEC_SWAP_BITS with rtx bitreverse

This is just expected to be a change in representation. No code is expected to change; no new tests are added. * config/cris/cris.md (CRIS_UNSPEC_SWAP_BITS): Remove. ("cris_swap_bits", "ctzsi2"): Use bitreverse instead. --- gcc/config/cris/cris.md | 9 ++--- 1 file changed, 2

[committed] dwarf2out.cc (mem_loc_descriptor): Handle BITREVERSE

Committed as obvious after regtest for cris-elf together with the "next" patch, that replaces unspec CRIS_UNSPEC_SWAP_BITS with bitreverse (which hit the ICE). -- >8 -- This seems to have just been overlooked when introducing BITREVERSE. Note that the function name mem_loc_descriptor is a

[PATCH] xtensa: Use HARD_REG_SET instead of bare integer

gcc/ChangeLog: * config/xtensa/xtensa.cc (machine_function, xtensa_expand_prologue): Change to use HARD_REG_BIT and its macros. * config/xtensa/xtensa.md (peephole2: regmove elimination during DFmode input reload): Likewise. --- gcc/config/xtensa/xtensa.cc

Re: [PATCH] Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178]

On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote: > > Indeed, this is a nice demonstration. > > While playing, I was wondering whether the following code is conforming: > > program p > call s ((1)) > contains > subroutine s (x) > integer :: x > x = 42 >

Re: [PATCH] libstdc++: Split up pstl/set.cc testcase

On Mon, 3 Jul 2023 at 23:14, Thomas Rodgers via Libstdc++ wrote: > > This testcase is causing some timeout issues. This patch splits the > testcase up by individual set algorithm. I think the Apache license requires a notice saying the original file was modified. A comment in each new file

[committed] libstdc++: Fix synopsis test

Tested x86_64-linux. Pushed to trunk. -- >8 -- The header is only supported for the cxx11 ABI. The declarations of basic_syncbuf, basic_osyncstream, syncbuf and osyncstream were already correctly guarded by a check for _GLIBCXX_USE_CXX11_ABI, but the wsyncbuf and wosyncstream declarations were

Re: [PATCH] libstdc++: Enable OpenMP 5.0 pragmas in PSTL headers

Pushed to trunk now. On Fri, 30 Jun 2023 at 21:17, Jonathan Wakely via Libstdc++ wrote: > > Jakub made a similar change a few yeas ago, but I think it got lost > in the recent PSTL rebase. > > Tested x86_64-linux. > > Does this look OK for trunk? > > -- >8 -- > > This reapplies

[committed] libstdc++: Qualify calls to std::_Destroy and _Destroy_aux

Tested x86_64-linux. Pushed to trunk. This isn't a regression, but is safe to backport. -- >8 -- These calls should be qualified to prevent ADL, which can cause errors for incomplete types that are associated classes. libstdc++-v3/ChangeLog: * include/bits/alloc_traits.h (_Destroy):

[PATCH] libstdc++: Split up pstl/set.cc testcase

This testcase is causing some timeout issues. This patch splits the testcase up by individual set algorithm. From 857359b72f8886b6e90db3b596d04f08559d2b51 Mon Sep 17 00:00:00 2001 From: Thomas Rodgers Date: Mon, 3 Jul 2023 15:04:45 -0700 Subject: [PATCH] libstdc++: Split up pstl/set.cc testcase

Re: [PATCH] tree-optimization/110310 - move vector epilogue disabling to analysis phase

Richard Biener writes: > The following removes late deciding to elide vectorized epilogues to > the analysis phase and also avoids altering the epilogues niter. > The costing part from vect_determine_partial_vectors_and_peeling is > moved to vect_analyze_loop_costing where we use the main loop >

Re: [PATCH v2] RISC-V: Add support for vector crypto extensions

Thanks, applied to master. --Philipp. On Mon, 3 Jul 2023 at 15:42, Kito Cheng wrote: > Thanks, LGTM :) > > Christoph Muellner 於 2023年7月3日 週一，19:08寫道： > >> From: Christoph Müllner >> >> This series adds basic support for the vector crypto extensions: >> * Zvbb >> * Zvbc >> * Zvkg >> * Zvkned >>

[PATCH 5/5] OpenMP: Array shaping operator and strided "target update" for C

Following the similar support for C++ and Fortran, here is the C implementation for the OpenMP 5.0 array-shaping operator, and for strided and rectangular updates for "target update". Much of the implementation is shared with the C++ support added earlier in this patch series. Some details of

[PATCH 4/5] OpenMP: Noncontiguous "target update" for Fortran

This patch implements noncontiguous "target update" for Fortran. The existing middle end/runtime bits relating to C++ support are reused, with some small adjustments, e.g.: 1. The node used to map the OMP "array descriptor" (from omp-low.cc onwards) now uses the OMP_CLAUSE_SIZE field as a

[PATCH 2/5] OpenMP: Allow complete replacement of clause during map/to/from expansion

At present, map/to/from clauses on OpenMP "target" directives may be expanded into several mapping nodes if they describe array sections with pointer or reference bases, or similar. This patch allows the original clause to be replaced during that expansion, mostly by passing the list pointer to

[PATCH 0/5] [og13] OpenMP: strides, rectangular updates and array-shaping operator for "target update"

This patch series adds support for the array-shaping operator from OpenMP 5.0, and strided and rectangular transfers for "target update" directives. The patches were previously posted for mainline here: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613785.html (C++)

[PATCH 1/5] OpenMP: Fix "exit data" for array sections for ref-to-ptr components

This patch fixes "exit data" for (C++) reference-to-pointer struct components with array sections, such as: struct S { int * [...] }; ... #pragma omp target exit data map(from: str->ptr, str->ptr[0:n]) Such exits need two "detach" operations. We need to unmap both the pointer and the

Re: [PATCH] Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178]

Hi Mikael, Am 03.07.23 um 13:46 schrieb Mikael Morin: A few thing to double check below. diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc index 30946ba3f63..16e8f037cfc 100644 --- a/gcc/fortran/trans-expr.cc +++ b/gcc/fortran/trans-expr.cc (...) @@ -6117,6 +6118,33 @@

[pushed] testsuite, Darwin: Remove an unnecessary flags addition.

This has been in use for some time in the Darwin branches that are used by downstream distributions. Re-tested on x86_64-darwin, pushed to trunk, thanks, Iain --- 8< --- The addition of the multiply_defined suppress flag has been handled for some considerable time now in the Darwin specs; remove

[PATCH] vect: Treat vector widening IFN calls as 'simple' [PR110436]

Hi, This patch makes the vectorizer treat any vector widening IFN as simple, like it did with the tree codes VEC_WIDEN_*. I wasn't sure whether I should make all IFN's simple and then exclude some (like GOMP_ ones), or include more than just the new widening IFNs. But since this is the only

[PATCH v2] libstdc++: PSTL dispatch for C++20 range random access iterators [PR110512]

libstdc++: Recognize C++ random access iterators as random access in PSTL [PR110432] The check for random access iterators in the PSTL only checks whether the iterator inherits from the random_access_iterator_tag, failing to recognize random access iterators originating in C++20 ranges and views.

Re: [PATCH] rs6000: Update the vsx-vector-6.* tests.

Kewen: On Fri, 2023-06-30 at 15:20 -0700, Carl Love wrote: > Segher never liked the above way of looking at the assembly. He > prefers: > gcc -S -g -mcpu=power8 -o vsx-vector-6-func-2lop.s vsx-vector-6- > func- > 2lop.c > > grep xxlor vsx-vector-6-func-2lop.s | wc > 34 68 516

RE: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

Sure, every change need test and will pay attention for this in future. Pan -Original Message- From: Robin Dapp Sent: Monday, July 3, 2023 10:57 PM To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches Cc: rdapp@gmail.com; jeffreyalaw ; Wang, Yanzhang ; kito.cheng Subject: Re:

Re: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

> Sorry for inconvenient, still working on fix it. If urgent I can > revert this change to unblock your work ASAP. I'm not blocked by this, thanks, just wanted to document it here. I was testing another patch and needed to dig for a while until I realized the FAILs come from this one. In general

RE: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

Sorry for inconvenient, still working on fix it. If urgent I can revert this change to unblock your work ASAP. Pan -Original Message- From: Robin Dapp Sent: Monday, July 3, 2023 10:49 PM To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches Cc: rdapp@gmail.com; jeffreyalaw ; Wang,

Re: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

Hmm, looks like it wasn't simple enough... I'm seeing execution fails for various floating point test cases. This is due to a mismatch between the FRM_DYN definition (0b111 == 7) and the attribute value (== 5). Therefore we set the rounding mode to 5 instead of 7. Regards Robin

[committed] tree+ggc: Change return type of predicate functions from int to bool

Also change internal variable from int to bool. gcc/ChangeLog: * tree.h (tree_int_cst_equal): Change return type from int to bool. (operand_equal_for_phi_arg_p): Ditto. (tree_map_base_marked_p): Ditto. * tree.cc (contains_placeholder_p): Update function body for bool return

RE: [PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

Committed as passed both the bootstrap and regression test, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Sandiford via Gcc-patches Sent: Monday, July 3, 2023 5:27 PM To: juzhe.zh...@rivai.ai Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de Subject: Re:

Re: [PATCH V7] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

juzhe.zh...@rivai.ai writes: > From: Ju-Zhe Zhong > > Hi, Richi and Richard. > > Base one the review comments from Richard: > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623405.html > > I change len_mask_gather_load/len_mask_scatter_store order into: > {len,bias,mask} > > We adjust adding

Re: [PATCH v2] RISC-V: Add support for vector crypto extensions

Thanks, LGTM :) Christoph Muellner 於 2023年7月3日 週一，19:08寫道： > From: Christoph Müllner > > This series adds basic support for the vector crypto extensions: > * Zvbb > * Zvbc > * Zvkg > * Zvkned > * Zvkhn[a,b] > * Zvksed > * Zvksh > * Zvkn > * Zvknc > * Zvkng > * Zvks > * Zvksc > * Zvksg > * Zvkt

Re: [PATCH v1] RISC-V: Fix one typo for emit_mode_set.

Lgtm juzhe.zh...@rivai.ai 於 2023年7月3日 週一，19:11寫道： > LGTM > > > > juzhe.zh...@rivai.ai > > From: pan2.li > Date: 2023-07-03 18:57 > To: gcc-patches > CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng > Subject: [PATCH v1] RISC-V: Fix one typo for emit_mode_set. > From: Pan Li > >

[COMMITTED] ada: Fix renaming of predefined equality operator for unchecked union types

From: Eric Botcazou The problem is that the predefined equality operator for unchecked union types is implemented out of line by invoking a function that takes more parameters than the two operands, which means that the renaming is not seen as type conforming with this function and, therefore,

[COMMITTED] ada: Fix discrepancy in expansion of untagged record equality

From: Eric Botcazou The expansion of the predefined equality operator for untagged record types can be done either in line, i.e. into the component-wise comparison of the operands, or out of line, i.e. into a call to a function implementing this comparison, and the heuristics of the selection

[COMMITTED] ada: Fix small inaccuracy in implementation of B.3.3(20/2)

From: Eric Botcazou This is the clause about inferable discriminants in unchecked unions. gcc/ada/ * sem_util.adb (Has_Inferable_Discriminants): In the case of a component with a per-object constraint, also return true if the enclosing object is not of an unchecked

Re: [PATCH] middle-end/110495 - avoid associating constants with (VL) vectors

On Mon, 3 Jul 2023, Richard Sandiford wrote: > Richard Biener via Gcc-patches writes: > > When trying to associate (v + INT_MAX) + INT_MAX we are using > > the TREE_OVERFLOW bit to check for correctness. That isn't > > working for VECTOR_CSTs and it can't in general when one considers > > VL

[PATCH] tree-optimization/110310 - move vector epilogue disabling to analysis phase

The following removes late deciding to elide vectorized epilogues to the analysis phase and also avoids altering the epilogues niter. The costing part from vect_determine_partial_vectors_and_peeling is moved to vect_analyze_loop_costing where we use the main loop analysis to constrain the epilogue

Re: [VSETVL PASS] RISC-V: Optimize local AVL propagation

LGTM. Regards Robin

Re: [PATCH] middle-end/110495 - avoid associating constants with (VL) vectors

Richard Biener via Gcc-patches writes: > When trying to associate (v + INT_MAX) + INT_MAX we are using > the TREE_OVERFLOW bit to check for correctness. That isn't > working for VECTOR_CSTs and it can't in general when one considers > VL vectors. It looks like it should work for COMPLEX_CSTs

[VSETVL PASS] RISC-V: Optimize local AVL propagation

I recently noticed that current VSETVL pass has a unnecessary restriction on local AVL propgation. Consider this following case: + insn 1: vsetvli a5,a3,e8,mf4,ta,mu + insn 2: vsetvli zero,a5,e32,m1,ta,ma + ... +

[PATCH] middle-end/110495 - avoid associating constants with (VL) vectors

When trying to associate (v + INT_MAX) + INT_MAX we are using the TREE_OVERFLOW bit to check for correctness. That isn't working for VECTOR_CSTs and it can't in general when one considers VL vectors. It looks like it should work for COMPLEX_CSTs but I didn't try to single out _Complex int in

Re: [PATCH] Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178]

Hello, Le 02/07/2023 à 22:38, Harald Anlauf via Fortran a écrit : Dear all, the attached patch fixes a long-standing issue with the order of evaluation of procedure argument expressions and deallocation of allocatable actual arguments passed to allocatable dummies with intent(out) attribute.

Re: [PATCH v1] RISC-V: Fix one typo for emit_mode_set.

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-07-03 18:57 To: gcc-patches CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Fix one typo for emit_mode_set. From: Pan Li This patch would like to fix one typo for scaler[should be scalar] in

[PATCH V7] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

From: Ju-Zhe Zhong Hi, Richi and Richard. Base one the review comments from Richard: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623405.html I change len_mask_gather_load/len_mask_scatter_store order into: {len,bias,mask} We adjust adding len and mask using using add_len_and_mask_args

[PATCH v2] RISC-V: Add support for vector crypto extensions

From: Christoph Müllner This series adds basic support for the vector crypto extensions: * Zvbb * Zvbc * Zvkg * Zvkned * Zvkhn[a,b] * Zvksed * Zvksh * Zvkn * Zvknc * Zvkng * Zvks * Zvksc * Zvksg * Zvkt This patch is based on the v20230620 version of the Vector Cryptography specification. The

Re: [PATCH] gcc-ar: Handle response files properly [PR77576]

I should also add that for a rsp file that contains just "--version": gcc-ar @rsp fails without the patch (current problem) and successfully prints the version info with it. On Sat, 1 Jul 2023 at 22:45, Costas Argyris wrote: > Basically implementing what Andrew said in the PR: > >

[PATCH v1] RISC-V: Fix one typo for emit_mode_set.

From: Pan Li This patch would like to fix one typo for scaler[should be scalar] in emit_mode_set, as well as minor change for mov emit. Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/riscv.cc (riscv_emit_mode_set): Fix typo. --- gcc/config/riscv/riscv.cc | 6 +++--- 1 file

Re: [PATCH] gimple-isel: Recognize vec_extract pattern.

On Mon, 3 Jul 2023, Robin Dapp wrote: > Hi, > > In gimple-isel we already deduce a vec_set pattern from an > ARRAY_REF(VIEW_CONVERT_EXPR). This patch does the same for a > vec_extract. > > The code is largely similar to the vec_set one including > the addition of a can_vec_extract_var_idx_p

[PATCH] gimple-isel: Recognize vec_extract pattern.

Hi, In gimple-isel we already deduce a vec_set pattern from an ARRAY_REF(VIEW_CONVERT_EXPR). This patch does the same for a vec_extract. The code is largely similar to the vec_set one including the addition of a can_vec_extract_var_idx_p function in optabs.cc to check if the backend can handle

Re: [PATCH 1/2] c++, libstdc++: implement __is_scalar built-in trait

Hi, Here is the benchmark result for is_scalar: https://github.com/ken-matsui/gcc-benches/blob/main/is_scalar.md#mon-jul--3-022250-am-pdt-2023 Time: -90.6237% Peak Memory Usage: -78.5155% Total Memory Usage: -82.1901% Sincerely, Ken Matsui On Mon, Jul 3, 2023 at 2:14 AM Ken Matsui wrote: > >

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

Commited, thanks Robin and Jeff. -- Original -- From: "juzhe.zh...@rivai.ai"

Re: [PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

> Similar to LEN_MASK_LOAD/STORE, their orders are consistent now after > this patch. Ah right, apologies. Regards Robin

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

Commited, thanks Robin, Kito, and Jeff. --Original-- From: "juzhe.zh...@rivai.ai"

Re: [PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

juzhe.zh...@rivai.ai writes: > From: Ju-Zhe Zhong > > Hi, Richard. I fix the order as you suggeted. > > Before this patch, the order is {len,mask,bias}. > > Now, after this patch, the order becomes {len,bias,mask}. > > Since you said we should not need 'internal_fn_bias_index', the bias index >

Re: Re: [PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

Take mask_store/MASK_STORE as example. In gimple IR: MASK_STORE (ptr, align, mask, v) In maskstore RTL IR maskstore (ptr, v, mask) For LEN_STORE/len_store, after adjusted: In gimple IR: LEN_STORE (ptr, align, len, bias, v) In len_store RTL IR len_store (ptr, v, len, bias) Similar to

Re: Re: [PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

No, we don't need to. len_load/len_store optab in backend (define_expand "len_load_v16qi" [(match_operand:V16QI 0 "register_operand") (match_operand:V16QI 1 "memory_operand") (match_operand:QI 2 "register_operand") (match_operand:QI 3 "vll_bias_operand") ] "TARGET_VX &&

Re: [PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

Hi Juzhe, when changing the argument order for LEN_LOAD/LEN_STORE, you will also need to adjust rs6000's and s390's expanders. Regards Robin

[PATCH 2/2] libstdc++: use new built-in trait __is_scalar for std::is_scalar

This patch gets std::is_scalar to dispatch to new built-in trait __is_scalar. libstdc++-v3/ChangeLog: * include/std/type_traits (is_scalar): Use __is_scalar built-in trait. (is_scalar_v): Likewise. Signed-off-by: Ken Matsui --- libstdc++-v3/include/std/type_traits | 14

[PATCH 1/2] c++, libstdc++: implement __is_scalar built-in trait

This patch implements built-in trait for std::is_scalar. The existent __is_scalar codes were replaced with is_scalar to avoid unintentional macro replacement by the new built-in. gcc/cp/ChangeLog: * cp-trait.def: Define __is_scalar. * constraint.cc (diagnose_trait_expr):

Re: [PATCH 2/2] ifcvt: Allow more operations in multiple set if conversion

Hi Manolis, that looks like a nice enhancement of what's already possible. The concern I had some years back already was that this function would eventually grow and cannibalize on some of what the other functions in ifcvt already do :) At some point we really should unify but that's not within

[PATCH 1/2] c++: implement __is_scalar built-in trait

This patch implements built-in trait for std::is_scalar. The existent __is_scalar codes were replaced with is_scalar to avoid unintentional macro replacement by the new built-in. gcc/cp/ChangeLog: * cp-trait.def: Define __is_scalar. * constraint.cc (diagnose_trait_expr):

Re: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

Thanks kito. Lehua will merge it for me. juzhe.zh...@rivai.ai From: Kito Cheng Date: 2023-07-03 17:01 To: Robin Dapp CC: juzhe.zh...@rivai.ai; jeffreyalaw; gcc-patches; Kito.cheng; palmer; palmer Subject: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering Tried on local,

[PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

From: Ju-Zhe Zhong Hi, Richard. I fix the order as you suggeted. Before this patch, the order is {len,mask,bias}. Now, after this patch, the order becomes {len,bias,mask}. Since you said we should not need 'internal_fn_bias_index', the bias index should always be the len index + 1. I notice

[PATCH] aarch64: Fix vector-to-vector vec_extract

The documentation says: - @cindex @code{vec_extract@var{m}@var{n}} instruction pattern @item @samp{vec_extract@var{m}@var{n}} Extract given field from the vector value. [...] The @var{n} mode is the mode of the field or

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

Tried on local, widen-complicate-7.c, widen-complicate-8.c and widen-complicate-9.c need those bridge pattern, otherwise will fail to combine, so give an explicitly LGTM from my side. On Mon, Jul 3, 2023 at 3:48 PM Robin Dapp via Gcc-patches wrote: > > To reiterate, this is OK from my side. As

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

OK. Thanks. Will commit with your cleanup patch. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-07-03 16:49 To: juzhe.zh...@rivai.ai CC: rdapp.gcc; jeffreyalaw; gcc-patches; kito.cheng; Kito.cheng; palmer; palmer Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering On 7/3/23

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 7/3/23 10:45, juzhe.zh...@rivai.ai wrote: > We can apply it but not sure why the patchwork shows it's rejected. I believe it also failed for me locally because the order of patterns in autovec-opt.md was somehow different. The one attached worked for me though after some minor merge

Re: [PATCH 0/9] vect: Move costing next to the transform for vect load

On Mon, Jul 3, 2023 at 5:39 AM Kewen.Lin wrote: > > Hi Richi, > > Thanks for your review comments on this and some others! > > on 2023/6/30 19:37, Richard Biener wrote: > > On Tue, Jun 13, 2023 at 4:07 AM Kewen Lin wrote: > >> > >> This patch series follows Richi's suggestion at the link [1], >

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

We can apply it but not sure why the patchwork shows it's rejected. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-07-03 16:44 To: juzhe.zh...@rivai.ai CC: rdapp.gcc; jeffreyalaw; gcc-patches; kito.cheng; Kito.cheng; palmer; palmer Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

> We failed to merge it since it's been rejected. > https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/ > > >   Err, who rejected? Or is this about

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

We failed to merge it since it's been rejected. https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/ juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-07-03 15:49 To: juzhe.zhong CC: rdapp.gcc; Jeff Law; gcc-patches; kito.cheng; kito.cheng;

RE: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

Committed, thanks Robin and Juzhe. Pan -Original Message- From: Robin Dapp Sent: Monday, July 3, 2023 4:15 PM To: juzhe.zh...@rivai.ai; Li, Pan2 ; gcc-patches Cc: rdapp@gmail.com; jeffreyalaw ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Fix one typo of FRM

Re: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

> Thanks for fixing it. LGTM. > I think you can merge it when Robin is ok since this is a simple typo > fix. Yes, that's definitely simple enough :) Regards Robin

Re: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

Thanks for fixing it. LGTM. I think you can merge it when Robin is ok since this is a simple typo fix. Thanks. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-07-03 16:08 To: gcc-patches CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Fix one typo of

[PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

From: Pan Li This patch would like to fix one typo that take rdn instead of dyn by mistake. Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/vector.md: Fix typo. --- gcc/config/riscv/vector.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors

On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote: > > On 6/29/23 6:55 PM, Richard Biener wrote: > > On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote: > >> > >> > >> > >> > >> > >> From: Richard Biener > >> Date: Tuesday, June 27, 2023 at 12:58 PM > >> To: Tejas Belagod > >> Cc:

Re: [PATCH] Use chain_next on eh_landing_pad_d for GTY (PR middle-end/110510)

On Sat, Jul 1, 2023 at 11:29 PM Andrew Pinski via Gcc-patches wrote: > > The backtrace in the bug report suggest there is a running out of > stack during GC collection, because of a long chain of eh_landing_pad_d. > This might fix that by adding chain_next onto eh_landing_pad_d's GTY marker. > >

Re: [PATCH 1/2] Fix PR 110487: invalid signed boolean value

On Sat, Jul 1, 2023 at 10:23 AM Andrew Pinski via Gcc-patches wrote: > > This fixes the first part of this bug where `a ? -1 : 0` > would cause a value of 1 into the signed boolean value. > It fixes the problem by casting to an integer type of > the same size/signedness before doing the negative

Re: [EXTERNAL] Re: [PATCH] Collect both user and kernel events for autofdo tests and autoprofiledbootstrap

On Sat, Jul 1, 2023 at 12:05 AM Eugene Rozenfeld wrote: > > I also set /proc/sys/kernel/perf_event_paranoid to 1 instead of the default 2. Does the perf attempt fail when the privileges are not adjusted and you specify --all? I see it adds /uk as flags, when I do > perf record -e

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

> Thanks. Ok for trunk？ OK from my side. As agreed with Jeff, I'm going to get back to this and revisit/change if needed in the future. Regards Robin

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

To reiterate, this is OK from my side. As discussed in the other thread, Jeff would like to have more info on whether a bridge pattern is needed at all and I agreed to get back to it in a while. Until then, we can merge this. Regards Robin

Re: [PATCH] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

juzhe.zh...@rivai.ai writes: > From: Ju-Zhe Zhong > > Hi, Richard and Richi. > > According to Richard's review comments: > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623405.html > > current len, bias and mask order is not reasonable. > > Change {len,mask,bias} into {len,bias,mask}. > >

Re: [PATCH] arm: Fix MVE intrinsics support with LTO (PR target/110268)

Ping? On Mon, 26 Jun 2023 at 17:02, Christophe Lyon wrote: > After the recent MVE intrinsics re-implementation, LTO stopped working > because the intrinsics would no longer be defined. > > The main part of the patch is simple and similar to what we do for > AArch64: > - call handle_arm_mve_h()

[PATCH] tree-optimization/110506 - ICE in pattern recog with TYPE_PRECISION

The following re-orders checks to make sure we check TYPE_PRECISION on an integral type. Bootstrap and regtest running on x86_6-unknown-linux-gnu. PR tree-optimization/110506 * tree-vect-patterns.cc (vect_recog_rotate_pattern): Re-order TYPE_PRECISION access with

[PATCH] tree-optimization/110506 - bogus non-zero mask in CCP for vector types

get_value_for_expr was blindlessly using TYPE_PRECISION to produce a mask for vector typed entities which the new tree checking now catches. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/110506 * tree-ssa-ccp.cc (get_value_for_expr): Check for

Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors

On 6/29/23 6:55 PM, Richard Biener wrote: On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote: From: Richard Biener Date: Tuesday, June 27, 2023 at 12:58 PM To: Tejas Belagod Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors On Tue, Jun 27,

[PATCH, rs6000] Extract the element in dword0 by mfvsrd and shift/mask [PR110331]

Hi, This patch implements the vector element extraction by mfvsrd and shift/mask when the element is in dword0 of the vector. Originally, it generates vsplat/mfvsrd on P8 and li/vextract on P9. Since mfvsrd has lower latency than vextract and rldicl has lower latency than vsplat, the new