Ooops, I just click send too fast, I want to say "Only few minor
comment on the md file"
On Thu, Jul 27, 2023 at 2:52 PM Kito Cheng wrote:
>
> Hi Juzhe-Zhong:
>
> Only
>
> > diff --git a/gcc/config/riscv/autovec-vls.md
> > b/gcc/config/riscv/autovec-vls.md
> > new file mode 100644
> > index
Hi Juzhe-Zhong:
Only
> diff --git a/gcc/config/riscv/autovec-vls.md b/gcc/config/riscv/autovec-vls.md
> new file mode 100644
> index 000..c67ff386e50
> --- /dev/null
> +++ b/gcc/config/riscv/autovec-vls.md
> +(define_insn_and_split "mov"
> + [(set (match_operand:VLS_AVL_IMM 0 "reg_or_mem
On Wed, 26 Jul 2023, Prathamesh Kulkarni wrote:
> Sorry, I meant PR110280 in subject line (not PR10280).
OK after 13.2 is released and the branch is open again.
Richard.
> On Wed, 26 Jul 2023 at 23:03, Prathamesh Kulkarni
> wrote:
> >
> > Hi Richard,
> > Sorry for the delay in backport to gcc-
On Wed, Jul 26, 2023 at 01:55:00 AM Andreas Schwab
wrote:
>
>On Jul 19 2023, Xiao Zeng wrote:
>
>> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
>> index 38d8eb2fcf5..7e6b24bd232 100644
>> --- a/gcc/config/riscv/riscv.cc
>> +++ b/gcc/config/riscv/riscv.cc
>> @@ -2448,6 +2448,
On 6/30/23 03:05, Nathaniel Shead wrote:
On Thu, Jun 29, 2023 at 01:43:07PM -0400, Jason Merrill wrote:
On 6/24/23 09:24, Nathaniel Shead wrote:
On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote:
Hi,
On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
Bootstrapped and te
> -Original Message-
> From: Yan Simonaytes
> Sent: Wednesday, July 26, 2023 2:11 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; Uros Bizjak ;
> Yan Simonaytes
> Subject: [PATCH] Replace invariant ternlog operands
>
> Sometimes GCC generates ternlog with three operands, but som
on 2023/7/26 18:02, Richard Biener wrote:
> On Wed, Jul 26, 2023 at 4:52 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> PR110776 exposes one issue that we could query unaligned
>> load for vector type but actually no unaligned vector load
>> is supported there. The reason is that the costed load is
>> with
> rtx_insn *last = BB_END (bb);
> emit_insn_before_noloc (gen_frrmsi (DYNAMIC_FRM_RTL (cfun)), last, bb);
The frrmsi insn need to be placed after CALL (aka last), then I bet here we
should use emit_insn_after_noloc.
Unfortunately, it will have ICE like below. I am still investigating the
sugge
Thanks Juzhe and Jeff for suggestion. The approach like emit_insn_before_noloc
will result in below ICE here.
../../../.././gcc/libstdc++-v3/libsupc++/new_opant.cc:42:1: error: flow control
insn inside a basic block.
../../../.././gcc/libstdc++-v3/libsupc++/new_opant.cc:42:1: internal compiler
Whoops, this should have gone in with the fixes to the RISC-V
diagnostics from earlier this week.
Committed to the trunk.
Jeff
commit 6f709f79c915a1ea82220a44e9f4a144d5eedfd1
Author: Jeff Law
Date: Wed Jul 26 19:25:33 2023 -0600
[committed] [RISC-V] Fix expected diagnostic messages in t
Hi Jason,
I've made the following changes.
1. Add pr83054-2.C
2. Move the devirt tests to tree-ssa.
3. Remove dg do run for devirt tests
4. Add // PR c++/110057
5. Generate commit message with git gcc-commit-mklog
6. Check commit format with git gcc-verify
Thanks!
On Thu, Jul 27, 2023 at 12:30
Thanks Jeff.
Hi, Pan:
Plz try (insert edge and put 'frrm' on that edge) instead of insert end of
block to see whether it works
(I have tried onece but I don't remember what happens).
Try that with following codes:
edge eg;
edge_iterator ei;
FOR_EACH_EDGE (eg, ei, bb->succs)
{
start_sequence ();
>> Any specific reason for MAX_BITS_PER_WORD instead of
>> GET_MODE_BITSIZE (Pmode)? In general I like the idea to switch
>> to scalar moves here but couldn't it already be debatable for
>> a 64-bit move on rv32 i.e. a question of costing?
V2SImode for example,
I think
I prefer this following
On 7/26/23 16:21, 钟居哲 wrote:
Hi, Jeff.
insert_insn_end_basic_block is to handle this following case:
bb 1:
...
CALL.>BB_END of bb
bb 2:
vfadd rne
You can see there is no instructions after CALL.
So you we use insert_insn_end_basic_block insert a "frrm" at the end of
the bb 1.
I know
On Wed, Jul 26, 2023 at 5:36 PM Jason Merrill wrote:
>
> On 6/30/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 accom
Hi, Jeff.
insert_insn_end_basic_block is to handle this following case:
bb 1:
...
CALL.>BB_END of bb
bb 2:
vfadd rne
You can see there is no instructions after CALL.
So you we use insert_insn_end_basic_block insert a "frrm" at the end of the bb
1.
I know typically it's better to insert a
On Wed, Jul 26, 2023 at 01:54:01PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> on 2023/7/11 03:59, 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 .
>
> It actually ha
On 7/26/23 07:08, Robin Dapp via Gcc-patches wrote:
So after thinking about it again - I'm still not really sure
I like treating every function as essentially an fesetround.
There is a reason why fesetround is special. Does LLVM behave
the same way?
But supposing we really, really want it an
On 6/30/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
On 7/19/23 04:11, Xiao Zeng wrote:
This patch completes the recognition of the basic semantics
defined in the spec, namely:
Conditional zero, if condition is equal to zero
rd = (rs2 == 0) ? 0 : rs1
Conditional zero, if condition is non zero
rd = (rs2 != 0) ? 0 : rs1
gcc/ChangeLog:
On 7/19/23 04:11, Xiao Zeng wrote:
This patch is the minimal support for Zicond extension, include
the extension name, mask and target defination.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: New extension.
* config/riscv/riscv-opts.h (MASK_ZICOND): New mask.
> I would like to propose that being focus and moving forward for this
> patch itself, the underlying other RVV floating point API support and
> the RVV instrinsic API fully tests depend on this.
Sorry, I didn't mean to ditch LCM/mode switching. I believe it is doing
a pretty good job and we shou
May I please ping this?
I am just about ready with the followup patch that fixes PR87299, but
it depends on this one. Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623364.html
-Lewis
On Fri, Jun 30, 2023 at 6:59 PM Lewis Hyatt wrote:
>
> In order to support processing #pragma in pr
On 7/26/23 15:32, Tamar Christina wrote:
+
+ cp_token *tok = pragma_tok;
+
+ do
{
- tok = cp_lexer_consume_token (parser->lexer);
- ivdep = cp_parser_pragma_ivdep (parser, tok);
- tok = cp_lexer_peek_token (the_parser->lexer);
+ switch
Hi Juzhe,
just some small remarks, all in all no major concerns.
> + vmv%m1r.v\t%0,%1"
> + "&& (!register_operand (operands[0], mode)
> + || !register_operand (operands[1], mode))"
> + [(const_int 0)]
> + {
> +unsigned size = GET_MODE_BITSIZE (mode).to_constant ();
> +if (size
On 6/28/23 06:35, Alex Coplan wrote:
Hi,
This patch implements clang's __has_feature and __has_extension in GCC.
This is a v2 of the original RFC posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html
Changes since v1:
- Follow the clang behaviour where -pedantic-errors
On Wed, Jul 26, 2023 at 09:33:22PM +0200, Harald Anlauf via Fortran wrote:
> I am going to get the brown bag for today... This is now the right
> corrected patch.
>
> Sorry for all the noise!
>
Third times a charm (as the saying goes).
Looks good to me. Thanks for the patch.
--
Steve
Hi, This is a respin of the patch taking in the feedback received from the C++
part.
Simultaneously it's also a ping 😊
Hi All,
FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should
not be applied to a particular loop.
ICC/ICX also has such a pragma for C and C+
I am going to get the brown bag for today... This is now the right
corrected patch.
Sorry for all the noise!
Harald
Am 26.07.23 um 21:17 schrieb Harald Anlauf via Gcc-patches:
Dear all,
the original submission missed the adjustments of the expected
patterns of 2 tests. This is corrected in
> > +
> > + cp_token *tok = pragma_tok;
> > +
> > + do
> > {
> > - tok = cp_lexer_consume_token (parser->lexer);
> > - ivdep = cp_parser_pragma_ivdep (parser, tok);
> > - tok = cp_lexer_peek_token (the_parser->lexer);
> > + switch (cp_parser_pragma_kind (tok))
> >
Dear all,
the original submission missed the adjustments of the expected
patterns of 2 tests. This is corrected in the new attachments.
Am 26.07.23 um 21:10 schrieb Harald Anlauf via Gcc-patches:
Dear all,
the attached patch fixes an ICE-on-invalid after use of strings of
non-constant length
Dear all,
the attached patch fixes an ICE-on-invalid after use of strings of
non-constant length in DATA statements.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b5b13db48c169ef18a8b75739bd4f22f9fd5654e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 26 Jul 2
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 precision of 1) */
(simplify
(rshift (nop_convert? (lshift @0 INT
Pushed to trunk.
-- >8 --
This new test uses uniform initialization syntax, so requires C++11 or
later.
libstdc++-v3/ChangeLog:
PR libstdc++/110807
* testsuite/23_containers/vector/bool/110807.cc: Require c++11.
---
libstdc++-v3/testsuite/23_containers/vector/bool/110807.cc | 2
On 7/19/23 04:11, Xiao Zeng wrote:
This patch completes the recognition of the basic semantics
defined in the spec, namely:
Conditional zero, if condition is equal to zero
rd = (rs2 == 0) ? 0 : rs1
Conditional zero, if condition is non zero
rd = (rs2 != 0) ? 0 : rs1
gcc/ChangeLog:
This final patch fixes an error introduced by patch 9/12 in this series.
I'll backport alongside the other patches once the 13 branch is unfrozen :)
On 7/25/23 18:22, Kito Cheng wrote:
OK for backport :)
On Wed, Jul 26, 2023 at 2:11 AM Patrick O'Neill wrote:
From: Martin Liska
Fixes:
gcc/co
Sorry, I meant PR110280 in subject line (not PR10280).
On Wed, 26 Jul 2023 at 23:03, Prathamesh Kulkarni
wrote:
>
> Hi Richard,
> Sorry for the delay in backport to gcc-13.
> The attached patch (cherry picked from master) is bootstrapped+tested
> on aarch64-linux-gnu with SVE enabled on gcc-13 br
Hi Richard,
Sorry for the delay in backport to gcc-13.
The attached patch (cherry picked from master) is bootstrapped+tested
on aarch64-linux-gnu with SVE enabled on gcc-13 branch.
OK to commit to gcc-13 branch ?
Thanks,
Prathamesh
[aarch64/match.pd] Fix ICE observed in PR110280.
gcc/ChangeLog:
On 7/26/23 12:57, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13 (later)?
OK.
-- >8 --
Now that init_subob_ctx no longer sets new_ctx.ctor for a subobject of
empty type, it seems we need to ensure its callers cxx_eval_bare_aggregate
and
On 7/26/23 12:57, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13 (after the branch is unfrozen)?
OK.
-- >8 --
This teaches unify how to compare two REAL_CSTs.
PR c++/110809
gcc/cp/ChangeLog:
* pt.cc (unify) : Generali
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13 (later)?
-- >8 --
Now that init_subob_ctx no longer sets new_ctx.ctor for a subobject of
empty type, it seems we need to ensure its callers cxx_eval_bare_aggregate
and cxx_eval_vec_init_1 consistently omit entries f
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13 (after the branch is unfrozen)?
-- >8 --
This teaches unify how to compare two REAL_CSTs.
PR c++/110809
gcc/cp/ChangeLog:
* pt.cc (unify) : Generalize to handle
REAL_CST as well.
gcc/test
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Ukrainian team of translators. The file is available at:
https://translationproject.org/latest/gcc/uk.po
(This file, 'gcc-13.1.0.uk.po', has
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
For backward compatibility we still want to allow patterns like
this->A::foo, but the template keyword in a qualified name is
specifically to specify that a dependent name is a template, so don't look
in the enclosing scope at all.
Also fix
On 7/26/23 12:00, Ng YongXiang wrote:
Hi Jason,
Thanks for the reply and review. I've attached an updated patch with the
change log and sign off.
The change made in gcc/testsuite/g++.dg/warn/pr83054.C is because I
think there is no more warning since we have already devirtualized the
destru
OK.
Thanks!
> [Changes from v1: fix merge issue in invoke.texi]
>
> This patch adds support for the general atomic operations introduced in
> eBPF v3. In addition to the existing atomic add instruction, this adds:
> - Atomic and, or, xor
> - Fetching versions of these operations (including add
On 7/26/23 02:21, Kito Cheng via Gcc-patches wrote:
My understanding is the semantic is slightly different, brev8 is only
the bit reverse within each byte, but bitreverse means did bit reverse
for the whole content of the mode, e.g. riscv_brev8_si will bit
reserved within 32 bit.
Using RV32 a
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 last bit
missing to fix this PR where the main fix w
C programmers increasingly use static to indicate that
pointer parameters are non-null. Clang can exploit this
for warnings and optimizations. GCC has some warnings
but not all warnings it has for nonnull. Below is a
patch to add a nonnull attribute automatically for such
arguments and to re
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 will come after
the 13.2 release.
-- >8 --
GCC thinks the allocation can alter the object being copied if it's
globally reachable, so doesn't realize that [x.begin(), x.end()) after
the allocation is the same as x.size() before it.
This ca
Tested x86_64-linux. Pushed to trunk.
Probably worth backporting to 12 and 13.
-- >8 --
We already have these attributes on the definitions in
but they don't work due to PR c++/84542. Add the attributes to the
declarations in as well, and add a test.
libstdc++-v3/ChangeLog:
* include
Hi Jason,
Thanks for the reply and review. I've attached an updated patch with the
change log and sign off.
The change made in gcc/testsuite/g++.dg/warn/pr83054.C is because I think
there is no more warning since we have already devirtualized the
destruction for the array.
Apologies for the poor
On Wed, 26 Jul 2023 08:34:14 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
I would say LCM/PRE is the key of this set of static rounding model
intrinsic, otherwise I think it's will push people to using dynamic with
fesetrouding mode or inline asm to set the rounding mode for performance
issue - it
Also reformat a comment that had too long lines.
Commit c5bd0e5870a introduced both these problems to fix.
Committed as obvious after ensuring that when running the testcase on
AArch64 it still fails before the original c5bd0e5870a commit and passes
after it.
gcc/ChangeLog:
* tree-vect-s
I would say LCM/PRE is the key of this set of static rounding model
intrinsic, otherwise I think it's will push people to using dynamic with
fesetrouding mode or inline asm to set the rounding mode for performance
issue - it's kind of opposite way of the design concept, we want to provide
a reliabl
Hi,
This patch enables the use of mixed-types for simd clones for AArch64
and adds aarch64 as a target_vect_simd_clones.
Bootstrapped and regression tested on aarch64-unknown-linux-gnu
gcc/ChangeLog:
* config/aarch64/aarch64.cc (currently_supported_simd_type):
Remove.
(aarch
This patch introduces a "symbol" base class that region and svalue
both inherit from, generalizing the ID from the region class so it's
also used by svalues. This gives a way of sorting regions and svalues
into creation order, which I've found useful in my experiments with
adding SMT support (PR a
As Juzhe mentioned, the problem of the CALL is resolved by LCM/PRE similar to
the VSETVL pass, which is well proofed up to a point.
I would like to propose that being focus and moving forward for this patch
itself, the underlying other RVV floating point API support and the RVV
instrinsic API f
On Wed, 2023-07-26 at 11:27 +0200, Benjamin Priour wrote:
> On Sat, Jul 22, 2023 at 12:04 AM David Malcolm
> wrote:
>
> > On Fri, 2023-07-21 at 17:35 +0200, Benjamin Priour wrote:
> > > Hi,
> > >
> > > Upon David's request I've joined the in progress patch to the
> > > below
> > > email.
> > > I
Explicitly backup and restore for each intrinsic just the same as we did for
CALL in this patch.
I can't have the data to prove how good we use LCM/PRE of mode switching but I
trust it.
Since the the LCM/PRE is the key optimization method of VSETVL PASS which is
doing good job on VSETVL instru
The testcase should use dg-additional-options instead of dg-options to
not overwrite default compile flags that include path for finding
the IEEE modules.
gcc/testsuite/ChangeLog:
* gfortran.dg/ieee/comparisons_3.F90: Use dg-additional-options
instead of dg-options.
Tested on x86_64-linu
> CSR write could be expensive, it will flush whole pipeline in some
> RISC-V core implementation…
Hopefully not flush but just sequentialize but yes, it's usually a
performance concern. However if we set the rounding mode to something
else for an intrinsic and then call a function we want to re
CSR write could be expensive, it will flush whole pipeline in some RISC-V
core implementation…
Kito Cheng 於 2023年7月26日 週三，21:57寫道：
> Sorry for late ack on the LLVM part, I can say they are did the same
> model/semantics, it done by our team member too, and I have regular meeting
> with that guy :
On 28/06/2023 11:35, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> This patch implements clang's __has_feature and __has_extension in GCC.
> This is a v2 of the original RFC posted here:
Ping. The Objective-C parts have been approved, but the C, C++, and generic bits
need review.
Let me know if t
Sorry for late ack on the LLVM part, I can say they are did the same
model/semantics, it done by our team member too, and I have regular meeting
with that guy :P
Robin Dapp via Gcc-patches 於 2023年7月26日 週三，21:47寫道：
> > current llvm didn't do any pre optimization. They always
> > backup+restore fo
> current llvm didn't do any pre optimization. They always
> backup+restore for each rounding mode intrinsic
I see. There is still the option of lazily restoring the
(entry) FRM before a function call but not read the FRM
after every call. Do we have any data on how good or bad the
mode-switchi
For clarification, the llvm side is lack of reference value, due to it will
always back up before vfadd, and then restore it after vfadd. For example as
below clang trunk code-gen.
test_float_point_dynamic_frm: # @test_float_point_dynamic_frm
vsetvli zero, a0, e32, m1, ta, ma
Thanks for catching and fixing David and Andrew.
Drew
On Tue, Jul 25, 2023 at 5:59 PM Andrew Pinski wrote:
> On Tue, Jul 25, 2023 at 1:54 PM Andrew Pinski wrote:
> >
> > On Tue, Jul 25, 2023 at 12:45 PM Jakub Jelinek via Gcc-patches
> > wrote:
> > >
> > > On Tue, Jul 25, 2023 at 03:42:21PM -0
Thanks Robin for comments.
Yes, you can reference this link to compare the difference between gcc and
llvm. And I am trying to understand and send the V8 later.
https://godbolt.org/z/4E434vaqv
Pan
From: juzhe.zhong
Sent: Wednesday, July 26, 2023 9:13 PM
To: Robin Dapp
Cc: Kito Cheng ; Li, Pa
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 last bit
missing to fix this PR where the main fix was already done by
r14-2117-gdd86a5a69cbda4
Bootstrapped and
So after thinking about it again - I'm still not really sure
I like treating every function as essentially an fesetround.
There is a reason why fesetround is special. Does LLVM behave
the same way?
But supposing we really, really want it and assuming there's consensus:
+ start_sequence ();
+ e
> Ah, thanks. In that case, Hao, I think we can avoid the ICE by changing:
>
> if ((kind == scalar_stmt || kind == vector_stmt || kind == vec_to_scalar)
> && vect_is_reduction (stmt_info))
>
> to:
>
> if ((kind == scalar_stmt || kind == vector_stmt || kind == vec_to_scalar)
> && ST
On Wed, Jul 26, 2023 at 2:26 PM Richard Biener
wrote:
>
> On Wed, Jul 26, 2023 at 9:21 AM Tejas Belagod wrote:
> >
> > On 7/17/23 5:46 PM, Richard Biener wrote:
> > > On Fri, Jul 14, 2023 at 12:18 PM Tejas Belagod
> > > wrote:
> > >>
> > >> On 7/13/23 4:05 PM, Richard Biener wrote:
> > >>> On T
On Wed, Jul 26, 2023 at 9:21 AM Tejas Belagod wrote:
>
> On 7/17/23 5:46 PM, Richard Biener wrote:
> > On Fri, Jul 14, 2023 at 12:18 PM Tejas Belagod
> > wrote:
> >>
> >> On 7/13/23 4:05 PM, Richard Biener wrote:
> >>> On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod
> >>> wrote:
>
> O
On Wed, Jul 26, 2023 at 12:12 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Wed, Jul 26, 2023 at 11:14 AM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Wed, Jul 26, 2023 at 4:02 AM Hao Liu OS via Gcc-patches
> >> > wrote:
> >> >>
> >> >> > When was STM
This patch is my proposed fix to PR rtl-optimization 110701, a latent bug
in combine's record_dead_and_set_regs_1 exposed by recent improvements to
simplify_subreg.
The issue involves the handling of (normal) SUBREG SET_DESTs as in the
instruction:
(set (subreg:HI (reg:SI x) 0) (expr:HI
Now that we can generically handle bitmasks for unary operators,
there's no need to special case them.
gcc/ChangeLog:
* range-op-mixed.h (class operator_cast): Add update_bitmask.
* range-op.cc (operator_cast::update_bitmask): New.
(operator_cast::fold_range): Call update_
Committed, thanks Kito and Juzhe.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, July 26, 2023 4:25 PM
To: juzhe.zh...@rivai.ai
Cc: Li Xu ; gcc-patches ;
palmer
Subject: Re: [PATCH] RISC-V: Fix vector tuple intrinsic
OK, thanks
On W
Clear the upper half of a V4SFmode operand register in front of all
potentially trapping instructions. The testcase:
--cut here--
typedef float v2sf __attribute__((vector_size(8)));
typedef float v4sf __attribute__((vector_size(16)));
v2sf test(v4sf x, v4sf y)
{
v2sf x2, y2;
x2 = __builtin_s
Richard Biener writes:
> On Wed, Jul 26, 2023 at 11:14 AM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Wed, Jul 26, 2023 at 4:02 AM Hao Liu OS via Gcc-patches
>> > wrote:
>> >>
>> >> > When was STMT_VINFO_REDUC_DEF empty? I just want to make sure that
>> >> > we're not pape
This patch fixes GCC to generate correct neg and neg32 instructions,
which do not take a source register operand. A couple of new tests
are added.
Tested in bpf-unknown-none.
gcc/ChangeLog
2023-07-26 Jose E. Marchesi
* config/bpf/bpf.md: Fix neg{SI,DI}2 insn.
gcc/testsuite/ChangeLo
On Wed, Jul 26, 2023 at 4:52 AM Kewen.Lin wrote:
>
> Hi,
>
> PR110776 exposes one issue that we could query unaligned
> load for vector type but actually no unaligned vector load
> is supported there. The reason is that the costed load is
> with single-lane vector type and its memory access type
On Wed, Jul 26, 2023 at 11:14 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Wed, Jul 26, 2023 at 4:02 AM Hao Liu OS via Gcc-patches
> > wrote:
> >>
> >> > When was STMT_VINFO_REDUC_DEF empty? I just want to make sure that
> >> > we're not papering over an issue elsewhere.
> >>
I stumbled recently over:
(a) 'omp target defaultmap(to: all)' - now added to the impl.status (as 'N')
(b) a @code that should have been @ref in our .texi
(c) while being there, I completed the 'Tasking Routines'
section by adding the missing, third routine omp_in_explicit_task.
(Documentation
Code hoisting part of GIMPLE PRE failed to adjust the TBAA behavior
of common loads in the case the alias set of the ref was the same
but the base alias set was not. It also failed to adjust the
base behavior, assuming it would match. The following plugs this
hole.
Bootstrapped and tested on x86
On Sat, Jul 22, 2023 at 12:04 AM David Malcolm wrote:
> On Fri, 2023-07-21 at 17:35 +0200, Benjamin Priour wrote:
> > Hi,
> >
> > Upon David's request I've joined the in progress patch to the below
> > email.
> > I hope it makes more sense now.
> >
> > Best,
> > Benjamin.
>
> Thanks for posting t
Richard Biener writes:
> On Wed, Jul 26, 2023 at 4:02 AM Hao Liu OS via Gcc-patches
> wrote:
>>
>> > When was STMT_VINFO_REDUC_DEF empty? I just want to make sure that we're
>> > not papering over an issue elsewhere.
>>
>> Yes, I also wonder if this is an issue in vectorizable_reduction. Below
On Wed, Jul 26, 2023 at 4:02 AM Hao Liu OS via Gcc-patches
wrote:
>
> > When was STMT_VINFO_REDUC_DEF empty? I just want to make sure that we're
> > not papering over an issue elsewhere.
>
> Yes, I also wonder if this is an issue in vectorizable_reduction. Below is
> the the gimple of "gcc.tar
gcc/ChangeLog:
* range-op.cc (class operator_absu): Add update_bitmask.
(operator_absu::update_bitmask): New.
---
gcc/range-op.cc | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index bfab53caea0..5653ca0d186 100644
--- a/gcc/range-op
gcc/ChangeLog:
* range-op-mixed.h (class operator_abs): Add update_bitmask.
* range-op.cc (operator_abs::update_bitmask): New.
---
gcc/range-op-mixed.h | 2 ++
gcc/range-op.cc | 6 ++
2 files changed, 8 insertions(+)
diff --git a/gcc/range-op-mixed.h b/gcc/range-op-mixed
gcc/ChangeLog:
* range-op-mixed.h (class operator_bitwise_not): Add update_bitmask.
* range-op.cc (operator_bitwise_not::update_bitmask): New.
---
gcc/range-op-mixed.h | 2 ++
gcc/range-op.cc | 7 +++
2 files changed, 9 insertions(+)
diff --git a/gcc/range-op-mixed.h b/g
It looks like we missed out on bitmasks for unary operators because we
were using bit_value_binop exclusively. This patch hands off to
bit_value_unop when appropriate, thus allowing us to handle ABS and
BIT_NOT_EXPR, and others. Follow-up patches will add the tweaks for the
range-ops entries them
On Tue, Jul 25, 2023 at 9:26 PM Drew Ross wrote:
>
> > With that fixed I think for non-vector integrals the above is the most
> > suitable
> > canonical form of a sign-extension. Note it should also work for any other
> > constant shift amount - just use the appropriate intermediate precision fo
OK, thanks
On Wed, Jul 26, 2023 at 4:22 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM from my side.
>
> It should be V3 though, never mind.
> No need to send V3 again.
>
> Give kito a chance chime in for more comments.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Li Xu
> Date
LGTM from my side.
It should be V3 though, never mind.
No need to send V3 again.
Give kito a chance chime in for more comments.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-07-26 16:18
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; Li Xu
Subject: [PATCH] RISC-V: Fix vector tuple intrins
commit, thanks :)
On Wed, Jul 26, 2023 at 3:39 PM Kito Cheng wrote:
>
> Oh, yeah, my bad, there is no fscsri, gonna test and push :)
>
> On Wed, Jul 26, 2023 at 3:20 PM juzhe.zh...@rivai.ai
> wrote:
> >
> > I just checked SPEC:
> >
> > fscsr rd, rs csrrw rd, fcsr, rs
> > Swap FP control/status r
My understanding is the semantic is slightly different, brev8 is only
the bit reverse within each byte, but bitreverse means did bit reverse
for the whole content of the mode, e.g. riscv_brev8_si will bit
reserved within 32 bit.
Using RV32 as example:
UNSPEC_BREV8:
rd[0...7] = rs[7...0]
rd[8...15
On Tue, Jul 25, 2023 at 9:08 PM Aldy Hernandez via Gcc-patches
wrote:
>
> bit_value_binop initializes VAL regardless of the final mask. It even
> has a comment to that effect:
>
> /* Ensure that VAL is initialized (to any value). */
>
> However, bit_value_unop, which in theory shares the same
Consider this following case:
void test_vsoxseg3ei32_v_i32mf2x3(int32_t *base, vuint32mf2_t bindex,
vint32mf2x3_t v_tuple, size_t vl) {
return __riscv_vsoxseg3ei32_v_i32mf2x3(base, bindex, v_tuple, vl);
}
Compiler failed with:
test.c:19:1: internal compiler error: in vl_vtype_info, at
config/r
A minor fix:
+#include
Better change it into:
+#include "riscv_vector.h"
Since we have a riscv_vector.h wrapper header added by kito.
I don't remember why we should use it. Maybe kito can answer it.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-07-26 16:00
To: gcc-patches
CC: kito.cheng; palm
1 - 100 of 107 matches
Mail list logo
