On Thu, Jan 11, 2024 at 2:16 AM Liu, Hongtao wrote:
>
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, January 10, 2024 5:44 PM
> > To: Liu, Hongtao
> > Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
> > ubiz...@gmail.com; bur...@net-b.de; san...@codesourcery.com
Hi,
This patch eliminates unnecessary byte swaps for block clear on P8
LE. For block clear, all the bytes are set to zero. The byte order
doesn't make sense. So the alignment of destination could be set to
the store mode size in stead of 1 byte in order to eliminates
unnecessary byte swap
On Thu, 11 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> As discussed on IRC, the following patch uses may_alias attribute, so that
> on targets like aarch64 where abi_limb_mode != limb_mode the library
> accesses the limbs (half limbs of the ABI) in the arrays with conservative
> alias set.
>
> So
"I didn't see theadvector-specific extension patterns. Could you show me?"
They are all in the file thead-vector.md.
For the sext/zext issue, perhaps I need some time to reproduce that
optimization,
but I can clearly remember it is related to vwmul.
Hi!
As discussed on IRC, the following patch uses may_alias attribute, so that
on targets like aarch64 where abi_limb_mode != limb_mode the library
accesses the limbs (half limbs of the ABI) in the arrays with conservative
alias set.
So far tested on x86_64-linux with
make check-gcc check-g++
This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(class th_extract): Define new builtin bases.
On Jan 7, 2024, "Kewen.Lin" wrote:
> As PR113100 shows, the unbiasing introduced by r14-6737 can
> cause the scrubbing to overrun and screw some critical data
> on stack like saved toc base consequently cause segfault on
> Power.
Ugh. Sorry about the breakage, and thanks for addressing it
sext/zext will be generated in O2 even without corresponding intrinsics.
--
发件人：juzhe.zh...@rivai.ai
发送时间：2024年1月11日(星期四) 17:07
收件人："cooper.joshua";
"gcc-patches"
抄 送：Jim Wilson; palmer;
andrew; "philipp.tomsich";
Thanks Richard, will delete the test case pr30957-1.c in patch V5.
Pan
-Original Message-
From: Richard Biener
Sent: Thursday, January 11, 2024 4:33 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
; kito.ch...@gmail.com; jeffreya...@gmail.com
To be specific, in CSE pass, the initial pattern will be optimized into the
sext/zext pattern.
--
发件人：joshua
发送时间：2024年1月11日(星期四) 17:11
收件人："juzhe.zh...@rivai.ai";
"gcc-patches"
抄 送：Jim Wilson; palmer;
andrew;
This patch fixes the following inefficient vectorized codes:
vsetvli a5,zero,e8,mf2,ta,ma
li a2,17
vid.v v1
li a4,-32768
vsetvli zero,zero,e16,m1,ta,ma
addiw a4,a4,104
vmv.v.i v3,15
lui a1,%hi(a)
li
On 2024-01-11, Uros Bizjak wrote:
On Thu, Jan 11, 2024 at 4:44 AM Fangrui Song wrote:
Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name). Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).
There isn't a good way
From: Pan Li
The insert_var_expansion_initialization depends on the
HONOR_SIGNED_ZEROS to initialize the unrolling variables
to +0.0f when -0.0f and no-signed-option. Unfortunately,
we should always keep the -0.0f here because:
* The -0.0f is always the correct initial value.
* We need to
Try to list all supported extensions: name, version and few description
for each extension.
gcc/ChangeLog:
* doc/invoke.texi (RISC-V Options): Add list of supported
extensions.
---
gcc/doc/invoke.texi | 463
1 file changed, 463
On Thu, 11 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> When we have a loop with more than 2 exits and a reduction I forgot to fill in
> the PHI value for all alternate exits.
>
> All alternate exits use the same PHI value so we should loop over the new
> PHI elements and copy the value
Hi, kito.
+@item zvl8192b
+@tab 1.0
+@tab Minimum vector length standard extensions
+
+@item zvl16384b
+@tab 1.0
+@tab Minimum vector length standard extensions
+
+@item zvl32768b
+@tab 1.0
+@tab Minimum vector length standard extensions
+
+@item zvl65536b
+@tab 1.0
+@tab Minimum vector length
LGTM now, thanks. I find it much more readable that way.
Regards
Robin
On Thu, Jan 11, 2024 at 9:33 AM Fangrui Song wrote:
>
> On 2024-01-11, Uros Bizjak wrote:
> >On Thu, Jan 11, 2024 at 4:44 AM Fangrui Song wrote:
> >>
> >> Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
> >> mangled name). Similar constraints are available in other
On Thu, Jan 11, 2024 at 2:39 AM wrote:
>
> From: Pan Li
>
> The insert_var_expansion_initialization depends on the
> HONOR_SIGNED_ZEROS to initialize the unrolling variables
> to +0.0f when -0.0f and no-signed-option. Unfortunately,
> we should always keep the -0.0f here because:
>
> * The
On Wed, Jan 10, 2024 at 07:05:39PM +, Andre Vieira (lists) wrote:
> This patch is still work in progress, but posting to show failure with
> bitint-7 test where handle_stmt called from lower_mergeable_stmt ICE's
> because the idx (3) is out of range for the __BitInt(135) with a limb_prec
> of
On Thu, Jan 11, 2024 at 9:24 AM Juzhe-Zhong wrote:
>
> This patch fixes the following inefficient vectorized codes:
>
> vsetvli a5,zero,e8,mf2,ta,ma
> li a2,17
> vid.v v1
> li a4,-32768
> vsetvli zero,zero,e16,m1,ta,ma
> addiw
The sext/zext issue is not related to xtheadvector-special patterns.
I added !TARGET_XTHEADVECTOR to sext/zext patterns in
"RISC-V: Handle differences between XTheadvector and Vector"
That is caused by the vwmul pattern, but I cannot reproduce it right now.
Maybe the optimization cannot be done in simple cases. We run some complex cases
in O2 and dsicovered it.
--
发件人：juzhe.zh...@rivai.ai
发送时间：2024年1月11日(星期四) 17:17
收件人："cooper.joshua";
"gcc-patches"
抄 送：Jim Wilson; palmer;
I think removing these changes for the "RISC-V: Handle differences between
XTheadvector and Vector" patch is better.
This is an extra e issue that can be handled in a seperate patch.
--
发件人：juzhe.zh...@rivai.ai
Oh. I see I think I have done wrong here.
I should adjust cost for VEC_EXTRACT not VEC_SET.
But it's odd, I didn't see loop vectorizer is scanning scalar_to_vec
cost in vect.dump.
The vect tree:
# a.4_25 = PHI <1(2), _4(11)>
# ivtmp_30 = PHI <18(2), ivtmp_20(11)>
# vect_vec_iv_.10_137 =
>> With a cost of "3" we still vectorize for zvl512b and larger.
>>Is that intended? I don't really see why 512 should vectorized
>>but 256 not. Disregarding that everything should be optimized
>>away, 2 iterations for the whole loop with 256 bits doesn't
>>seem that bad.
Yeah... I just
Fix build warning:
mips.cc: warning: unused parameter 'decl'.
gcc
* config/mips/mips.cc (mips_start_function_definition):
Add ATTRIBUTE_UNUSED.
---
gcc/config/mips/mips.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/config/mips/mips.cc
On Thu, Jan 11, 2024 at 10:52 AM Robin Dapp wrote:
>
> On 1/11/24 10:46, juzhe.zh...@rivai.ai wrote:
> > Oh. I see I think I have done wrong here.
> >
> > I should adjust cost for VEC_EXTRACT not VEC_SET.
> >
> > But it's odd, I didn't see loop vectorizer is scanning scalar_to_vec
> > cost in
On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
>On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
>
>
>
>> libstdc++-v3/ChangeLog:
> Yeah... I just noticed. I should set it as 4 to fix it with biggest VLEN
> size,
> that is, -march=rv64gcv_zvl4096b --param=riscv-autovec-lmul=m8...
>
> I am confused now how to fix this case.
4 is definitely too high compared to a regular instruction.
vmv.vx could even be zero-cost for
On Thu, Jan 11, 2024 at 11:18 AM Richard Biener
wrote:
>
> On Thu, Jan 11, 2024 at 11:20 AM juzhe.zh...@rivai.ai
> wrote:
> >
> > Ok I see your idea and we need to adjust scalar_to_vec accurately. Inside
> > the loop we have these 2 scalar_to_vec:
> >
> > 1. MIN_EXPR 1 times scalar_to_vec
>> (My question whether why we shouldn't vectorize this at 256b
>> and above still stands, though)
I think we shouldn't vectorize it with any vlen, since the non-vectorized
codegen is much better.
And also, I have tested -msve-vector-bits=2048, ARM SVE doesn't vectorize it.
-zvl65536b, RVV Clang
On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
>
> This patch made std::filesystem::equivalent correctly throw an exception
> when either path does not exist as per [fs.op.equivalent]/4.
Thanks, OK for trunk and all active branches (let me know if you need
help backporting it).
>
>
On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> >
> >> libstdc++-v3/ChangeLog:
> >
> >> * src/filesystem/ops-common.h (stat_type): Use using.
>
Do you mean removing TARGET_XTHEADVECTOR for sext/zext patterns
and then resending the "RISC-V: Handle differences between XTheadvector
and Vector" patch?
--
发件人：juzhe.zh...@rivai.ai
发送时间：2024年1月11日(星期四) 17:57
On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
>
> On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> > >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> > >
> > >> libstdc++-v3/ChangeLog:
> > >
>
without CSE:
(insn 16 15 17 2 (set (reg/v:RVVM2HI 137 [ output_var_0 ])
(if_then_else:RVVM2HI (unspec:RVVMF8BI [
(const_vector:RVVMF8BI repeat [
(const_int 1 [0x1])
])
(reg:DI 146)
On Thu, Jan 11, 2024 at 9:30 AM HAO CHEN GUI wrote:
>
> Hi,
> This patch eliminates unnecessary byte swaps for block clear on P8
> LE. For block clear, all the bytes are set to zero. The byte order
> doesn't make sense. So the alignment of destination could be set to
> the store mode size in
Thanks Richard.
So you think increase scalar_to_vec cost is not the correct approach to fix
this case?
Or could you give me a suggestion to fix this case ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2024-01-11 17:18
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; kito.cheng;
I see. We added ! TARGET_THEADVECTOR initally becasue
we want to provide a patchset version that can work without any
errors both in O0 and O2. Without these changes, we will get "
unrecognized opcode" in O2 during assembly stage.
On Fri, Dec 29, 2023 at 11:29 AM Feng Xue OS
wrote:
>
> This patch is meant to fix over-estimation about SLP vector-to-scalar cost for
> STMT_VINFO_LIVE_P statement. When pattern recognition is involved, a
> statement whose definition is consumed in some pattern, may not be
> included in the
On Thu, Jan 11, 2024 at 10:46 AM Richard Biener
wrote:
>
> On Fri, Dec 29, 2023 at 11:29 AM Feng Xue OS
> wrote:
> >
> > This patch is meant to fix over-estimation about SLP vector-to-scalar cost
> > for
> > STMT_VINFO_LIVE_P statement. When pattern recognition is involved, a
> > statement
>> The slidedown/vmv.x.s part is of course vec_extract but we indeed
>> don't seem to cost it as vec_to_scalar here.
>
> It looks like a vectorized live operation as it's not in the loop body
> (and thus really irrelevant for costing in practice). This has
>
> /* ??? Enable for loop
>> That said, we also don't really cost all our vsetvls yet (difficult...).
If cost vsetvl, we will need to cost 1 more for each STMT.
However, it is not accurate. Since our VSETVL PASS will eliminate redundancy...
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-11 18:09
To: Richard
On Thu, Jan 11, 2024 at 11:20 AM juzhe.zh...@rivai.ai
wrote:
>
> Ok I see your idea and we need to adjust scalar_to_vec accurately. Inside the
> loop we have these 2 scalar_to_vec:
>
> 1. MIN_EXPR 1 times scalar_to_vec costs 1 in prologue
>
>This scalar_to_vec cost should be 0 or 1 since it
Committed, thanks Richard.
Pan
-Original Message-
From: Richard Biener
Sent: Thursday, January 11, 2024 5:22 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
; kito.ch...@gmail.com; jeffreya...@gmail.com
Subject: Re: [PATCH v5] LOOP-UNROLL: Leverage
On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely wrote:
> On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
> >
> > This patch made std::filesystem::equivalent correctly throw an exception
> > when either path does not exist as per [fs.op.equivalent]/4.
>
> Thanks, OK for trunk and all active
On Thu, 11 Jan 2024 at 10:56, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely wrote:
> > On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
> > >
> > > This patch made std::filesystem::equivalent correctly throw an exception
> > > when either path does not exist as per
> I think we shouldn't vectorize it with any vlen, since the non-vectorized
> codegen is much better.
> And also, I have tested -msve-vector-bits=2048, ARM SVE doesn't vectorize it.
> -zvl65536b, RVV Clang also doesn't vectorize it.
Of course I agree that optimizing everything to return 0 is
Due to the premature split optimizations for XTheadFMemIdx, GPR
is allocated when reload allocates registers, resulting in the
following insn.
(insn 66 21 64 5 (set (reg:DF 14 a4 [orig:136 ] [136])
(mem:DF (plus:SI (reg/f:SI 15 a5 [141])
(ashift:SI (reg/v:SI 10 a0
On Thu, Jan 11, 2024 at 9:50 AM wrote:
>
> From: Pan Li
>
> The insert_var_expansion_initialization depends on the
> HONOR_SIGNED_ZEROS to initialize the unrolling variables
> to +0.0f when -0.0f and no-signed-option. Unfortunately,
> we should always keep the -0.0f here because:
>
> * The
This patch made std::filesystem::equivalent correctly throw an exception
when either path does not exist as per [fs.op.equivalent]/4.
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&.
* src/filesystem/ops.cc (fs::equivalent): Likewise.
This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(class th_extract): Define new builtin bases.
On 1/11/24 10:46, juzhe.zh...@rivai.ai wrote:
> Oh. I see I think I have done wrong here.
>
> I should adjust cost for VEC_EXTRACT not VEC_SET.
>
> But it's odd, I didn't see loop vectorizer is scanning scalar_to_vec
> cost in vect.dump.
The slidedown/vmv.x.s part is of course vec_extract but
Alex Coplan writes:
> This is a v3 which addresses shortcomings of the v2 patch. v2 was
> posted here:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642448.html
>
> The main issue in v2 is that we were using the final (transformed)
> patterns in combine_reg_notes instead of the
And also I have investigate LLVM cost model. They don't cost vsevli in
vectorization cost model.
But their cost model does a good job...
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-11 18:09
To: Richard Biener
CC: rdapp.gcc; juzhe.zh...@rivai.ai; gcc-patches; kito.cheng; Kito.cheng;
libstdc++-v3/ChangeLog:
* src/filesystem/ops-common.h (stat_type): Use using.
Signed-off-by: Ken Matsui
---
libstdc++-v3/src/filesystem/ops-common.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/src/filesystem/ops-common.h
The problem here is after the recent vectorizer improvements, we end up
with a comparison against a vector bool 0 which then tries
expand_single_bit_test
which is not expecting vector comparisons at all.
The IR was:
vector(4) mask_patt_5.13;
_Bool _12;
mask_patt_5.13_44 =
Pushed to r14-7134.
在 2024/1/11 上午9:07, Yang Yujie 写道:
LTO option streaming and target attributes both require per-function
target configuration, which is achieved via option save/restore.
We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
context in addition to other
Oh, Sorry. I made a mistake. It's -mrvv-vector-bits=2048 RVV clang doesn't
vectorize it.
But ARM SVE GCC doesn't fix the issue if we specify -msve-vector-bits=2048, it
will vectorize it.
https://godbolt.org/z/x7s8Kz87a
I guess LLVM has some magic in their cost model which can work well.
Hi, Robin.
I model scalar value initialization accurately with following patch:
+/* Adjust vectorization cost after calling
+ targetm.vectorize.builtin_vectorization_cost. For some statement, we would
+ like to further fine-grain tweak the cost on top of
+
On Thu, 11 Jan 2024 at 11:28, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
> > On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> > >
> > > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely
> > > wrote:
> > > >On Thu, 11 Jan 2024, 09:43 Ken Matsui,
libstdc++-v3/ChangeLog:
* src/filesystem/ops-common.h (stat_type): Use using.
Signed-off-by: Ken Matsui
---
libstdc++-v3/src/filesystem/ops-common.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/src/filesystem/ops-common.h
On Thu, 11 Jan 2024, 09:43 Ken Matsui, wrote:
> libstdc++-v3/ChangeLog:
>
> * src/filesystem/ops-common.h (stat_type): Use using.
>
> Signed-off-by: Ken Matsui
> ---
> libstdc++-v3/src/filesystem/ops-common.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Thu, Jan 11, 2024 at 5:24 AM Andrew Pinski wrote:
>
> Since currently ranger does not work with the complexity of COND_EXPR in
> some cases so delaying the simplification of `1/x` for signed types
> help code generation.
> tree-ssa/divide-8.c is a new testcase where this can help.
Huh. It
Ok I see your idea and we need to adjust scalar_to_vec accurately. Inside the
loop we have these 2 scalar_to_vec:
1. MIN_EXPR 1 times scalar_to_vec costs 1 in prologue
This scalar_to_vec cost should be 0 or 1 since it only generate single
instructions: vmv.v.i v16,15
2. 32872 >> patt_26 1
On 1/11/24 11:20, juzhe.zh...@rivai.ai wrote:
> Ok I see your idea and we need to adjust scalar_to_vec accurately. Inside the
> loop we have these 2 scalar_to_vec:
>
> 1. MIN_EXPR 1 times scalar_to_vec costs 1 in prologue
>
> This scalar_to_vec cost should be 0 or 1 since it only generate
On Thu, Jan 11, 2024 at 11:34 AM Andrew Pinski wrote:
>
> The problem here is after the recent vectorizer improvements, we end up
> with a comparison against a vector bool 0 which then tries
> expand_single_bit_test
> which is not expecting vector comparisons at all.
>
> The IR was:
>
This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share
On Thu, Jan 11, 2024 at 09:53:33AM +0100, Jakub Jelinek wrote:
> On Wed, Jan 10, 2024 at 07:05:39PM +, Andre Vieira (lists) wrote:
> > This patch is still work in progress, but posting to show failure with
> > bitint-7 test where handle_stmt called from lower_mergeable_stmt ICE's
> > because
On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
> On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> > >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> > >
> > >> libstdc++-v3/ChangeLog:
> > >
> >
We found that the current combine optimization pass in gcc cannot handle
the following redundant sign extension situations:
(insn 77 76 78 5 (set (reg:SI 143)
(plus:SI (subreg/s/u:SI (reg/v:DI 104 [ len ]) 0)
(const_int 1 [0x1]))) {addsi3}
(expr_list:REG_DEAD (reg/v:DI 104
Eliminate the redundant sign extension that exists after the conditional
move when the target register is SImode.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_expand_conditional_move):
Adjust.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/sign-extend-2.c:
diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index 0c146aba44d2..c89cdb8fb2ef 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -36,7 +36,7 @@ be sponsored by an existing maintainer (someone with "write
after approval"
is not sufficient).
If you already have an
On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely wrote:
> On Thu, 11 Jan 2024 at 10:56, Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely wrote:
> > > On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
> > > >
> > > > This patch made std::filesystem::equivalent correctly throw
Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name). Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).
There isn't a good way for x86 yet, e.g. "i" doesn't work for
PIC/-mcmodel=large. This patch adds "Ws". Here
Tested x86_64-linux. Does this look better now?
It also fixes PR113320 that got reported.
-- >8 --
I seem to have implemented this feature based on the P2918R0 revision,
not the final P2918R2 one that was approved for C++26. This commit fixes
it.
The runtime-format-string type should not have
This is version 2 of the patch. The only difference is I made the test case
simpler to read.
In looking at support for load vector pair and store vector pair for the
PowerPC in GCC, I noticed that we were missing a print_operand output modifier
if you are dealing with vector pairs to print the
I was finding it frustrating when returning from a function in GDB and
the return value was shown as $1 = { }, so this makes it
print std::true_type or std::false_type.
There are some contexts where the output isn't ideal, e.g. a type
derived from std::true_type will now show something like:
$2
Here's an updated patch to include the change from this PATCH:
https://gcc.gnu.org/pipermail/jit/2023q4/001763.html
On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:
> On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds support for getting the CPU features
This WIP patch adds preliminary and very lightly-tested support for
the "begin declare variant" and "end declare variant" directives of
OpenMP 5.1. I am posting it now for logistical reasons, rather than
because I believe it is immediately ready for review.
Some notes follow on the
On Fri, 12 Jan 2024 at 00:16, Jonathan Wakely wrote:
>
> I'd like to commit this to trunk for GCC 14. Please take a look.
Without looking at it in excruciating detail, it's pretty much along
the lines of what I have always envisioned
to be a powerful combination of concepts and if-constexpr. My
This fixes a regression introduced by the LWG 3809 change, so is needed
on trunk and gcc-13 and gcc-12.
Tested x86_64-linux and aarch64-linux.
-- >8 --
I implemented the resolution of LWG 3809 in r13-4364-ga64775a0edd469 but
more recently it was noted that the change causes possible truncation
On Tue, Jan 09, 2024 at 04:35:22PM -0600, Peter Bergner wrote:
> ...and this is really ugly and hard to read/understand. Can't we use
> register variables to make it simpler? Something like the following
> which tests having both FPR and Altivec reg numbers assigned?
>
> ...
> void
> test
On Thu, 2024-01-11 at 01:00 +0100, Guillaume Gomez wrote:
> Hi David.
>
> Thanks for the review!
>
> > > +.. function:: void\
> > > + gcc_jit_lvalue_add_string_attribute
> > > (gcc_jit_lvalue *variable,
> > > + enum
> > >
On Linux/x86_64,
897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737 is the first bad commit
commit 897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737
Author: Richard Biener
Date: Thu Jan 11 12:02:43 2024 +0100
tree-optimization/113126 - vector extension compare optimization
caused
FAIL: gcc.dg/pr15784-1.c
Hello,
You are absolutely right, we can't throw all side-effects away.
Example:
```c++
auto __attribute__ ((noinline)) bar()
{
volatile int* b = (int *)0xff;
*b = 10;
volatile auto n = nullptr;
return n; // Problem (1)
}
int* foo_2()
{
volatile
Now in patch form!
Any further comments?
---
htdocs/codingconventions.html | 60 +++
1 file changed, 60 insertions(+)
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f5a356a8..2bbf6670 100644
--- a/htdocs/codingconventions.html
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As discussed, our handling of corresponding object parameters needed to
handle the using-declaration case better. And I took the opportunity to
share code between the add_method and cand_parms_match uses.
This patch specifically doesn't
Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only.
Reviews requested.
-- >8 --
This is a step towards implementing the C++23 change P2408R5, "Ranges
iterators as inputs to non-Ranges algorithms". C++20 random access
iterators which do not meet the C==17RandomAccessIterator
On Wed, 10 Jan 2024 at 18:28, François Dumont wrote:
>
> libstdc++: [_GLIBCXX_DEBUG] Fix assignment of value-initialized iterator
> [PR112477]
>
> Now that _M_Detach do not reset iterator _M_version value we need to
> reset it when
> the iterator is attached to a new sequence. Even if this
> 1. This patch set scalar_to_vec cost as 2 instead 1 since scalar move
>instruction is slightly more costly than normal rvv instructions (e.g.
> vadd.vv).
We can go with 2 or 3 (if needed) for now but should later
really incorporate reg-move costs in this IMHO. Just like e.g.
static const
On Thu, Jan 11, 2024 at 04:33:10PM -0500, Jason Merrill wrote:
> Now in patch form!
>
> Any further comments?
It looks good to me, but it doesn't say if we want to put a space
after } and before () if we're invoking the lambda (I suppose we
want that space). As in
... = [&] (tree arg) { ...
On Thu, 2024-01-11 at 22:40 +0100, Guillaume Gomez wrote:
> Hi David,
>
> > The above looks correct, but the patch adds the entrypoint
> > descriptions
> > to topics/types.rst, which seems like the wrong place. The
> > function-
> > related ones should be in topics/functions.rst in the
On Thu, 11 Jan 2024 at 16:12, Patrick Palka wrote:
>
> On Thu, 11 Jan 2024, Jonathan Wakely wrote:
>
> > On Wed, 10 Jan 2024 at 21:40, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > This avoids redundant moves when
Verify that if-conversion succeeded through noce_try_store_flag_mask, as
per PR rtl-optimization/105314, tightening the test case and making it
explicit.
gcc/testsuite/
* gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too.
---
gcc/testsuite/gcc.target/riscv/pr105314.c |
On Tue, 9 Jan 2024 at 22:00, Jonathan Wakely wrote:
>
> Does anybody see any problem with making this change, so that we avoid
> the problem described in the PR?
Pushed to trunk. We should backport this too.
>
> -- >8 --
>
> As described in PR libstdc++/113258 there are old versions of tcmalloc
On Wed, 10 Jan 2024 at 23:31, Jonathan Wakely wrote:
>
> On Wed, 10 Jan 2024 at 21:28, Michael Levine (BLOOMBERG/ 120 PARK)
> wrote:
> >
> > From a67cfd07ce27a62f764b381268502acb68b6bad9 Mon Sep 17 00:00:00 2001
> > From: Michael Levine
> > Date: Wed, 10 Jan 2024 15:48:46 -0500
> > Subject:
And a follow-up to fix the obvious typo in the first word.
Pushed to trunk and gcc-13.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Fix spelling.
* doc/html/manual/api.html: Regenerate.
---
libstdc++-v3/doc/html/manual/api.html | 6 --
Hi David,
> The above looks correct, but the patch adds the entrypoint descriptions
> to topics/types.rst, which seems like the wrong place. The function-
> related ones should be in topics/functions.rst in the "Functions"
> section and the lvalue/variable one in topics/expression.rst after the
1 - 100 of 197 matches
Mail list logo
