On Thu, Jul 27, 2023 at 11:38 PM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> while looking on profile misupdate on hmmer I noticed that loop splitting
> pass is not
> able to handle the loop it has as an example it should apply on:
>
>One transformation of loops like:
>
>for (i = 0; i <
I didn't checked with rvv intrinsic spec, but I assume this is found during
test with api test, so LGTM, thanks for fixing this:)
juzhe.zh...@rivai.ai 於 2023年7月28日 週五 14:43 寫道：
> Thanks for fixing it.
> LGTM from my side.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Li Xu
> Date: 2023-07-28 13:52
> To
Thanks for fixing it.
LGTM from my side.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-07-28 13:52
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; pan2.li; xuli
Subject: [PATCH] RISC-V: Remove vxrm parameter for vsadd[u] and vssub[u]
From: xuli
Computation of `vsadd`, `vsaddu`, `vssub`,
On Fri, Jul 28, 2023 at 8:38 AM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> while looking on profile misupdate on hmmer I noticed that loop splitting
> pass is not
> able to handle the loop it has as an example it should apply on:
>
>One transformation of loops like:
>
>for (i = 0; i < 1
On Fri, Jul 28, 2023 at 8:34 AM Andrew Pinski wrote:
>
> On Sun, Jul 23, 2023 at 1:39 AM Richard Biener via Gcc-patches
> wrote:
> >
> >
> >
> > > Am 23.07.2023 um 01:27 schrieb Andrew Pinski via Gcc-patches
> > > :
> > >
> > > This adds a special case of the `(a&~b) | b` pattern where
> > > `b
Hi,
while looking on profile misupdate on hmmer I noticed that loop splitting pass
is not
able to handle the loop it has as an example it should apply on:
One transformation of loops like:
for (i = 0; i < 100; i++)
{
if (i < 50)
A;
else
B;
}
in
On Thu, Jul 27, 2023 at 10:43:00 PM Jeff Law wrote:
>
>
>
>On 7/27/23 02:43, Xiao Zeng wrote:
>
>>
>> 2. According to your opinions, I have modified the code, but out of caution
>> for upstream, I conducted a complete regression tests on patch V2, which took
>> some time. I was unable to reply to
On Sun, Jul 23, 2023 at 1:39 AM Richard Biener via Gcc-patches
wrote:
>
>
>
> > Am 23.07.2023 um 01:27 schrieb Andrew Pinski via Gcc-patches
> > :
> >
> > This adds a special case of the `(a&~b) | b` pattern where
> > `b` and `~b` are comparisons.
> >
> > OK? Bootstrapped and tested on x86_64-li
On Wed, Jul 26, 2023 at 8:19 PM Drew Ross wrote:
>
> Here is what I came up with for combining the two:
>
> /* For (x << c) >> c, optimize into x & ((unsigned)-1 >> c) for
>unsigned x OR truncate into the precision(type) - c lowest bits
>of signed x (if they have mode precision or a precis
On Fri, Jul 28, 2023 at 12:23 AM David Malcolm via Gcc-patches
wrote:
>
> On Tue, 2023-04-11 at 08:43 +, Richard Biener wrote:
> > On Tue, 4 Apr 2023, David Malcolm wrote:
> >
> > > Richi, Jakub: I can probably self-approve this, but it's
> > > technically a
> > > new feature. OK if I push th
From: xuli
Computation of `vsadd`, `vsaddu`, `vssub`, and `vssubu` do not need the
rounding mode, therefore the intrinsics of these instructions do not have
the parameter for rounding mode control.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc: remove rounding mode of
vs
This patch uses _GLIBCXX_HAS_BUILTIN_TRAIT macro instead of
__has_builtin in the type_traits header. This macro supports to toggle
the use of built-in traits in the type_traits header through
_GLIBCXX_NO_BUILTIN_TRAITS macro, without needing to modify the
source code.
libstdc++-v3/ChangeLog:
This patch defines _GLIBCXX_HAS_BUILTIN_TRAIT macro, which will be used
as a flag to toggle the use of built-in traits in the type_traits header
through _GLIBCXX_NO_BUILTIN_TRAITS macro, without needing to modify the
source code.
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX_
Sorry for not consider rv32 config.
The fix is OK. If convenient, please commit it.
On 2023/7/28 4:46, Patrick O'Neill wrote:
> The newly added testcase fails on rv32 targets with this message:
> FAIL: gcc.target/riscv/rvv/autovec/madd-split2-1.c -O3 -ftree-vectorize (test
> for excess errors)
>
On 7/27/23 18:59, Lewis Hyatt wrote:
In order to support processing #pragma in preprocess-only mode (-E or
-save-temps for gcc/g++), we need a way to obtain the #pragma tokens from
libcpp. In full compilation modes, this is accomplished by calling
pragma_lex (), which is a symbol that must be exp
From: Pan Li
Update in PATCH v8:
1. Emit non-abnormal backup insn to edge.
2. Fix _after return when call.
3. Refine some run tests.
4. Cleanup code.
Original commit logs:
In basic dynamic rounding mode, we simply ignore call instructions and
we would like to take care of call in this PATCH.
On 7/23/23 20:26, Ben Boeckel wrote:
On Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote:
It occurs to me that the model I am envisioning is similar to CMake's object
libraries. Object libraries are a convenient name for a bunch of object files.
IIUC they're linked by naming the indivi
In order to support processing #pragma in preprocess-only mode (-E or
-save-temps for gcc/g++), we need a way to obtain the #pragma tokens from
libcpp. In full compilation modes, this is accomplished by calling
pragma_lex (), which is a symbol that must be exported by the frontend, and
which is cur
On 7/27/23 15:27, Jose E. Marchesi wrote:
>
> Hi David.
> Thanks for the patch.
>
>> BPF ISA V4 introduces sign-extending move and load operations. This
>> patch makes the BPF backend generate those instructions, when enabled
>> and useful.
>>
>> A new option, -m[no-]smov gates generation of
Hi David.
Thanks for the patch.
> BPF ISA V4 introduces sign-extending move and load operations. This
> patch makes the BPF backend generate those instructions, when enabled
> and useful.
>
> A new option, -m[no-]smov gates generation of these instructions, and is
> enabled by default for -mcpu
Hi David, thanks for the patch.
OK.
> This patch makes some minor cleanups to eBPF options documented in
> invoke.texi:
> - Delete some vestigal docs for removed -mkernel option
> - Add -mbswap and -msdiv to the option summary
> - Note the negative versions of several options
> - Note that
On Tue, 2023-04-11 at 08:43 +, Richard Biener wrote:
> On Tue, 4 Apr 2023, David Malcolm wrote:
>
> > Richi, Jakub: I can probably self-approve this, but it's
> > technically a
> > new feature. OK if I push this to trunk in stage 4? I believe
> > it's
> > low risk, and is very useful for ben
BPF ISA V4 introduces sign-extending move and load operations. This
patch makes the BPF backend generate those instructions, when enabled
and useful.
A new option, -m[no-]smov gates generation of these instructions, and is
enabled by default for -mcpu=v4 and above. Tests for the new
instructions
This patch makes some minor cleanups to eBPF options documented in
invoke.texi:
- Delete some vestigal docs for removed -mkernel option
- Add -mbswap and -msdiv to the option summary
- Note the negative versions of several options
- Note that -mcpu=v4 also enables -msdiv.
gcc/
* doc/i
Hi Tobias!
On 2023-07-25T23:45:54+0200, Tobias Burnus wrote:
> The attached patch calls CUDA's cuMemcopy2D and cuMemcpy3D
> for omp_target_memcpy_rect[,_async} for dim=2/dim=3. This should
> speed up the data transfer for noncontiguous data.
ACK, thanks.
> While being there, I ended up adding s
The newly added testcase fails on rv32 targets with this message:
FAIL: gcc.target/riscv/rvv/autovec/madd-split2-1.c -O3 -ftree-vectorize (test
for excess errors)
verbose log:
compiler exited with status 1
output is:
cc1: error: ABI requires '-march=rv32'
Something like this appears to fix the
Dear all,
when passing a character actual argument to an assumed-type dummy
(TYPE(*)), we should not pass the character length for that argument,
as otherwise other hidden arguments that are passed as part of the
gfortran ABI will not be interpreted correctly. This is in line
with the current way
On Linux/x86_64,
7931a1de9ec87b996d51d3d60786f5c81f63919f is the first bad commit
commit 7931a1de9ec87b996d51d3d60786f5c81f63919f
Author: Jonathan Wakely
Date: Wed Jul 26 14:09:24 2023 +0100
libstdc++: Avoid bogus overflow warnings in std::vector [PR110807]
caused
FAIL: 23_containers/vec
I think there should be tests for _Atomic _BitInt types. Hopefully atomic
compound assignment just works via the logic for compare-and-exchange
loops, but does e.g. atomic_fetch_add work with _Atomic _BitInt types?
--
Joseph S. Myers
jos...@codesourcery.com
> Am 27.07.2023 um 19:12 schrieb Roger Sayle :
>
>
> Hi Richard,
>
> You're 100% right. It’s possible to significantly clean-up this code,
> replacing
> the body of the conditional with a call to force_reg and simplifying the
> conditions
> under which it is called. These improvements ar
Excerpts from Andreas Schwab via Gcc-patches's message of Juli 24, 2023 11:15
am:
> Ping?
>
OK from me.
Thanks,
Iain.
> The pseudo-C output templates for these instructions were incorrectly
> using operand 1 rather than operand 2 on the RHS, which led to some
> very incorrect assembly generation with -masm=pseudoc.
>
> Tested on bpf-unknown-none.
> OK?
OK. Thanks for spotting and fixing this!
>
> gcc/
>
>
On Thu, 27 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
> - _BitInt(N) bit-fields aren't supported yet (the patch rejects them); I'd
> like
> to enable those incrementally, but don't really see details on how such
> bit-fields should be laid-out in memory nor passed inside of function
> a
Hi,
as discussed with Richard, we want store to be likely in
optimize_mask_stores.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
* tree-vect-loop.cc (optimize_mask_stores): Make store
likely.
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 256155
This patch fixes profile update after RTL unroll, that is now done same way as
in tree one. We still produce (slightly) corrupted profile for multiple exit
loops I can try to fix incrementally.
I also updated testcases to look for profile mismatches so they do not creep
back in again.
Bootstrapp
The pseudo-C output templates for these instructions were incorrectly
using operand 1 rather than operand 2 on the RHS, which led to some
very incorrect assembly generation with -masm=pseudoc.
Tested on bpf-unknown-none.
OK?
gcc/
* config/bpf/bpf.md (add3): Use %w2 instead of %w1
On Thu, Jul 27, 2023 at 07:15:28PM +0200, Jakub Jelinek via Gcc-patches wrote:
> testcases, I've been using
> https://defuse.ca/big-number-calculator.htm
> tool, a randombitint tool I wrote (will post as a reply to this) plus
> LLVM trunk on godbolt and the WIP GCC support checking if both compiler
Hi!
This patch adds the C FE support, c-family support, small libcpp change
so that 123wb and 42uwb suffixes are handled plus glimits.h change
to define BITINT_MAXWIDTH macro.
The previous two patches really do nothing without this, which enables
all the support.
2023-07-27 Jakub Jelinek
Hi!
This patch adds the library helpers for multiplication, division + modulo
and casts from and to floating point.
As described in the intro, the first step is try to reduce further the
passed in precision by skipping over most significant limbs with just zeros
or sign bit copies. For multiplica
Hi Richard,
You're 100% right. It’s possible to significantly clean-up this code, replacing
the body of the conditional with a call to force_reg and simplifying the
conditions
under which it is called. These improvements are implemented in the patch
below, which has been tested on x86_64-pc-li
[PATCH 0/5] GCC _BitInt support [PR102989]
The following patch series introduces support for C23 bit-precise integer
types. In short, they are similar to other integral types in many ways,
just aren't subject for integral promotions if smaller than int and they can
have even much wider precisions
Yet another omission, the flag was not properly set for deeply buried
'omp teams' as I stopped too early when walking up the stack.
Now fixed by commit r14-2826-g081e25d3cfd86c
* * *
This was found when 'repairing' the feature on the OG13
(devel/omp/gcc-13) branch for metadirectives, cf. the se
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
A decimal point was being added to the end of the string for {:#.0}
because the __expc character was not being set, for the _Pres_none
presentation type, so __s.find(__expc) didn't the 'e' in "1e+01" and so
we created "1
On 7/27/23 02:43, Xiao Zeng wrote:
2. According to your opinions, I have modified the code, but out of caution
for upstream, I conducted a complete regression tests on patch V2, which took
some time. I was unable to reply to emails and upload patch V2 in a timely
manner.
Sorry to have waste
Hi,
This patch fixes profile update in tree_transform_and_unroll_loop which is used
by predictive comming. I stared by attempt to fix
gcc.dg/tree-ssa/update-unroll-1.c I xfailed last week, but it turned to be
harder job.
Unrolling was never fixed for changes in duplicate_loop_body_to_header_edge
Hi,
this fixes two bugs in tree-ssa-loop-im.cc. First is that cap probability is
not
reliable, but it is constructed with adjusted quality. Second is that sometimes
the conditional has wrong joiner BB count. This is visible on
testsuite/gcc.dg/pr102385.c however the testcase triggers another pr
Hi,
profile_count::apply_probability misses check for uninitialized
probability which leads to completely random results on applying
uninitialized probability to initialized scale. This can make
difference when i.e. inlining -fno-guess-branch-probability function to
-fguess-branch-probability one.
Prevent rtl optimization of vec_duplicate + zero_extend to
vpbroadcastm since there could be an extra kmov after RA.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
Ready to push to trunk.
gcc/ChangeLog:
PR target/110788
* config/i386/sse.md (avx512cd_maskb_vec_dup): Add
On Thu, Jul 27, 2023 at 01:07:58PM +, Richard Biener wrote:
> On Thu, 27 Jul 2023, Jakub Jelinek wrote:
>
> > On Thu, Jul 27, 2023 at 12:00:56PM +, Richard Biener wrote:
> > > The following fixes the lack of simplification of a vector shift
> > > by an out-of-bounds shift value. For scala
On Thu, 27 Jul 2023, Jakub Jelinek wrote:
> On Thu, Jul 27, 2023 at 12:00:56PM +, Richard Biener wrote:
> > The following fixes the lack of simplification of a vector shift
> > by an out-of-bounds shift value. For scalars this is done both
> > by CCP and VRP but vectors are not handled there.
On Thu, Jul 27, 2023 at 12:00:56PM +, Richard Biener wrote:
> The following fixes the lack of simplification of a vector shift
> by an out-of-bounds shift value. For scalars this is done both
> by CCP and VRP but vectors are not handled there. This results
> in PR91838 differences in outcome
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Thursday, July 27, 2023 6:50 PM
To: Li, Pan2
Cc: GCC Patches ; 钟居哲 ; Wang,
Yanzhang
Subject: Re: [PATCH v1] RISC-V: Remove unnecessary vread_csr/vwrite_csr
intrinsic.
Ok, thanks:)
Pan Li via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> 於
> LGTM, I just found this patch still on the list, I mostly tested with
> qemu, so I don't think that is a problem before, but I realize it's a
> problem when we run on a real board that does not support those
> extensions.
I think we can skip this one as I needed to introduce vector_hw and
zvfh_h
The following fixes the lack of simplification of a vector shift
by an out-of-bounds shift value. For scalars this is done both
by CCP and VRP but vectors are not handled there. This results
in PR91838 differences in outcome dependent on whether a vector
shift ISA is available and thus vector low
My first impression is those emit_insn (gen_rtx_SET()) seems
necessary, but I got the point after I checked vector.md :P
Committed to trunk, thanks :)
On Thu, Jul 27, 2023 at 6:23 PM juzhe.zh...@rivai.ai
wrote:
>
> Oh, YES.
>
> Thanks for fixing it. It makes sense since the ternary operations i
LGTM, I just found this patch still on the list, I mostly tested with
qemu, so I don't think that is a problem before, but I realize it's a
problem when we run on a real board that does not support those
extensions.
On Sun, Jun 18, 2023 at 6:07 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 6/15/2
On Thu, 13 Jul 2023, Jeff Law via Gcc-patches wrote:
> > Question for the experts: how is this handled? Do I need to apply this
> > change to my workspace and commit it, with Mikael as the change author?
> That's what I usually do for someone without write access. commit it locally
> using the -
Ok, thanks:)
Pan Li via Gcc-patches 於 2023年7月27日 週四 18:45 寫道：
> From: Pan Li
>
> According to below RVV doc, the related intrinsic is not longer needed.
>
> https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/249
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * config/riscv/riscv
From: Pan Li
According to below RVV doc, the related intrinsic is not longer needed.
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/249
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv_vector.h (enum RVV_CSR): Removed.
(vread_csr): Ditto.
(vwrite_csr
The following XFAILs recognizing a complex store as memset.
Tested on x86_64-unknown-linux-gnu, pushed to trunk and branch.
PR tree-optimization/110829
* gcc.dg/pr56837.c: XFAIL part of the testcase.
---
gcc/testsuite/gcc.dg/pr56837.c | 2 +-
1 file changed, 1 insertion(+), 1 del
>> Hmmm, does it mean we'll have (set (mem) (mem)) after legitimize_move???
The answer is yes. It's odd I know.
And I found the regression fail, for mem to mem pattern, I change it into:
(define_insn_and_split "*mov_mem_to_mem"
[(set (match_operand:VLS_AVL_IMM 0 "memory_operand")
(match_
> Yes, potentially similar for all the other ifs but I didn't check
> all of them.
Thanks and sure thing, will clean up this in v8.
> if (mode != no_mode && mode != last_mode)
> {
This comes from after not the emit part as I mentioned, I am not quit familiar
with this part, as well as if the a
Oh, YES.
Thanks for fixing it. It makes sense since the ternary operations in "vector.md"
generate "vmv.v.v" according to RA.
Thanks for fixing it.
@kito: Could you confirm it? If it's ok to you, commit it for Han (I am lazy to
commit patches :).
juzhe.zh...@rivai.ai
From: demin.han
Date:
I change as follows:
(define_insn_and_split "*mov_mem_to_mem"
[(set (match_operand:VLS_AVL_IMM 0 "memory_operand")
(match_operand:VLS_AVL_IMM 1 "memory_operand"))]
"TARGET_VECTOR && can_create_pseudo_p ()"
"#"
"&& 1"
[(const_int 0)]
{
if (GET_MODE_BITSIZE (mode).to_constant
Hmmm, does it mean we'll have (set (mem) (mem)) after legitimize_move???
Or maybe try to
use define_insn_and_split rather than define_split for the (set (mem) (mem))
On Thu, Jul 27, 2023 at 5:50 PM juzhe.zh...@rivai.ai
wrote:
>
> Hi, kito.
> I tried to reject mem->mem in this pattern:
> (define
When pass split2 starts, which_alternative is random depending on
last set of certain pass.
Even initialized, the generated movement is redundant.
The movement can be generated by assembly output template.
Signed-off-by: demin.han
gcc/ChangeLog:
* config/riscv/autovec.md: Delete which_
Hi, kito.
I tried to reject mem->mem in this pattern:
(define_insn_and_split "*mov"
[(set (match_operand:VLS_AVL_IMM 0 "reg_or_mem_operand" "=vr, m, vr")
(match_operand:VLS_AVL_IMM 1 "reg_or_mem_operand" " m,vr, vr"))]
"TARGET_VECTOR
&& (register_operand (operands[0], mode)
|
The following turns the recursive post-dominator traversal in GIMPLE
code sinking to a worklist.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-sink.cc (sink_code_in_bb): Remove recursion, instead
use a worklist ...
(pass_sink_code::execute): ... i
Last minor thing :)
> +(define_insn_and_split "*mov"
> + [(set (match_operand:VLS_AVL_IMM 0 "reg_or_mem_operand" "=vr, m, vr")
> + (match_operand:VLS_AVL_IMM 1 "reg_or_mem_operand" " m,vr, vr"))]
> + "TARGET_VECTOR"
Reject (set (mem) (mem)) by adding the check:
TARGET_VECTOR
&& (registe
Address comments.
V3:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625618.html
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-27 14:52
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: [PATCH V2] RISC-V: Enable basic VLS modes support
Hi Juzhe-Zhong
On Wed, Jul 26, 2023 at 01:51:00 AM Jeff Law wrote:
>
>
>
>On 7/19/23 04:11, Xiao Zeng wrote:
>> Hi all RISC-V folks:
>>
>> This series of patches completes support for the riscv architecture's
>> Zicond standard extension instruction set.
>>
>> Currently, Zicond is in a frozen state.
>>
>> See t
> I see, you mean at the beginning of frm_after, we can just return the
> incoming mode as is?
>
> If (CALL_P (insn))
> return mode; // Given we aware the mode is DYN_CALL already.
Yes, potentially similar for all the other ifs but I didn't check
all of them.
> Thank and will cleanup this i
> so there is no need to appear to change the mode but we can just pass it
> through, possibly same for DYN? Or to put it differently, can we start
> with "return mode" in riscv_frm_mode_after and then only add the condition
> that are strictly necessary?
I see, you mean at the beginning of frm_a
> ../../../.././gcc/libstdc++-v3/libsupc++/eh_personality.cc:805:1: internal
> compiler error: in insert_insn_on_edge, at cfgrtl.cc:1976.
This error comes from assert of insert_insn_on_edge, the edge cannot be
ABNORMAL and CRITIAL.
Thus, I try to filter out it like gcse.cc:2168 do like below, b
On Wed, 26 Jul 2023, Jeff Law wrote:
>
>
> On 7/26/23 07:27, Richard Biener via Gcc-patches wrote:
> > The following patch makes sure to elide a redundant permute that
> > can be merged with existing splats represented as load permutations
> > as we now do for non-grouped SLP loads. This is the
>> Why do we appear to return a different mode here? We already request
>> FRM_MODE_DYN_CALL in mode_needed. It looks like in the whole function
>> we do not change the mode so we could just always return the incoming
>> mode?
>
> Because we need to emit 2 insn when meet a call. One before the c
On Linux/x86_64,
ade30fad6669e5f34ca4c587c724d74ecc953175 is the first bad commit
commit ade30fad6669e5f34ca4c587c724d74ecc953175
Author: Uros Bizjak
Date: Wed Jul 26 11:10:46 2023 +0200
i386: Clear upper half of XMM register for V2SFmode operations [PR110762]
caused
FAIL: gcc.target/i38
77 matches
Mail list logo
