Hi Andrew,
On Fri, 2023-05-05 08:17:19 -0700, Andrew Pinski via Gcc-patches
wrote:
> While looking into a different issue, I noticed that it
> would take until the second forwprop pass to do some
> forward proping and it was because the ssa name was
> used more than once but the second
Hi Juzhe,
Thanks for taking the time to review the code. I will address comments 1, 2, 3.
For comment 4, it is necessary to implement these hooks. The purpose is to
mark functions that use vector registers to pass arguments and return value so
that they can be recognized by the linker. Send the
Previously, Richi has suggested that vcond patterns are only needed when target
support comparison + select consuming 1 instruction.
Now, I do the experiments on removing those "vcond" patterns, it works
perfectly.
All testcases PASS.
Really appreicate Richi helps us recognize such issue.
Now
From: Ju-Zhe Zhong
Hi, this patch is to add LEN_MASK_STORE into SCCVN.
LEN_MASK_STORE is predicated by both len and mask together.
My understanding is that LEN_MASK_STORE has same rhs_off and offset as
MASK_STORE.
The size = MIN (length (deduced from mask), (len + bias)).
Not sure my
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 honor just prefer_vecotr_width_type and other flags that
may cause safety issue so caller can get more optimization opportunity.
From: Ju-Zhe Zhong
Line 3292: has variable name "len": tree mask = NULL_TREE, len = NULL_TREE,
bias = NULL_TREE;
Line 3349: has variable name "len": HOST_WIDE_INT start = 0, len = 0;
Since they are never used simultaneously, such issue is not recognized for now.
However, I want to add
Hi,
For function with target attribute arch=*, current logic will set its
tune to -mtune from command line so all target_clones will get same
tuning flags which would affect the performance for each clone. Override
tune with arch if tune was not explicitly specified to get proper tuning
flags for
hi Jeff
Please see my earlier reply here.
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg310656.html
Maybe you scrolled past it in so many emails:)
BR,
Fei
On 2023-06-25 21:36 Jeff Law wrote:
>
>
>
>On 6/20/23 03:40, Fei Gao wrote:
>> gcc/ChangeLog:
>>
>> * shrink-wrap.cc
Hi,
Since PR96435, both boolean objects and expressions have been evaluated
in the following way by the D front-end.
(*(ubyte*)_or_expr) & 1
It has been noted that sometimes this can cause the back-end to optimize
in non-obvious ways - in particular with __builtin_expect.
This @safe
From: Ju-Zhe Zhong
gcc/ChangeLog:
* tree-ssa-dse.cc (initialize_ao_ref_for_dse): Add LEN_MASK_STORE.
(dse_optimize_stmt): Ditto.
---
gcc/tree-ssa-dse.cc | 27 +++
1 file changed, 27 insertions(+)
diff --git a/gcc/tree-ssa-dse.cc b/gcc/tree-ssa-dse.cc
From: Ju-Zhe Zhong
Hi, previous I made a mistake on GIMPLE_FOLD of LEN_MASK_{LOAD,STORE}.
We should fold LEN_MASK_{LOAD,STORE} (bias+len) == vf (nunits instead of
bytesize) && mask = all trues mask
into:
MEM_REF [...].
This patch added testcase to test gimple fold of
On Mon, Jun 26, 2023 at 9:31 AM liuhongt via Gcc-patches
wrote:
>
> The new assembly looks better than original one, so I adjust those testcases.
> Ok for trunk?
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/110371
> PR tree-optimization/110018
> *
When there're multiple operands in vec_oprnds0, vec_dest will be
overwrited to vectype_out, but in multi_step_cvt case, cvt_type is
expected. It caused an ICE when verify_gimple_in_cfg.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,} and aarch64-linux-gnu.
Ok for trunk?
gcc/ChangeLog:
The new assembly looks better than original one, so I adjust those testcases.
Ok for trunk?
gcc/testsuite/ChangeLog:
PR tree-optimization/110371
PR tree-optimization/110018
* gcc.target/aarch64/sve/unpack_fcvt_signed_1.c: Scan scvt +
sxtw instead of scvt + zip1 +
> > Hmm, good question. GENERIC has a direct truncation to unsigned char
> > for example, the C standard generally says if the integral part cannot
> > be represented then the behavior is undefined. So I think we should be
> > safe here (0x1.0p32 doesn't fit an int).
>
> We should be following
Hi,
This backports patch from upstream dmd mainline for fixing PR110113.
The data being Mem.xrealloc'd contains many Array(T) fields, some of
which have self references in their data.ptr field thanks to the
smallarray optimization used by Array.
Naturally then, the memcpy from old GC data to
On Sun, Jun 25, 2023 at 9:35 PM Jan Beulich wrote:
>
> On 25.06.2023 09:30, Hongtao Liu wrote:
> > On Sun, Jun 25, 2023 at 3:23 PM Hongtao Liu wrote:
> >>
> >> On Sun, Jun 25, 2023 at 3:13 PM Hongtao Liu wrote:
> >>>
> >>> On Sun, Jun 25, 2023 at 1:52 PM Jan Beulich wrote:
>
> On
Hi,
This patch merges the D front-end and run-time library with upstream dmd
5f7552bb28, and standard library with phobos 106038f2e.
Synchronizing with the latest bug fixes in the v2.103.1 release.
D front-end changes:
- Import dmd v2.103.1.
- Deprecated invalid special token
On Sun, Jun 25, 2023, at 8:49 AM, Jeff Law wrote:
> On 6/24/23 19:40, Stefan O'Rear wrote:
>> On Sat, Jun 24, 2023, at 11:01 AM, Jeff Law via Gcc-patches wrote:
>>> On 6/21/23 02:14, Wang, Yanzhang wrote:
Hi Jeff, sorry for the late reply.
> The long branch handling is done at the
On Fri, Jun 23, 2023 at 14:31:17 -0400, Jason Merrill wrote:
> On 6/20/23 15:46, Ben Boeckel wrote:
> > On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote:
> >> On 1/25/23 13:06, Ben Boeckel wrote:
>
> >>> Header units (including the standard library headers) are 100%
> >>> unsupported
On Fri, Jun 23, 2023 at 10:44:11 -0400, Jason Merrill wrote:
> On 1/25/23 16:06, Ben Boeckel wrote:
> > It affects the build, and if used as a static file, can reliably be
> > tracked using the `-MF` mechanism.
>
> Hmm, this seems a bit like making all .o depend on the Makefile; it
Technically
On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote:
> On 6/22/23 22:45, Ben Boeckel wrote:
> > On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote:
> >> On 1/25/23 16:06, Ben Boeckel wrote:
> >>> They affect the build, so report them via `-MF` mechanisms.
> >>
> >> Why isn't this
> > Also as discussed some time ago, the volatile loads between traps has
> > effect of turning previously pure/const functions into non-const which
> > is somewhat sad, so it is still on my todo list to change it this stage1
> > to something more careful. We discussed internal functions
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Sunday, June 25, 2023 8:55 PM
To: juzhe.zh...@rivai.ai; Li Xu ; gcc-patches
Cc: kito.cheng ; palmer ; zhengyu
Subject: Re: [PATCH v2] RISC-V: fix expand function of
Thanks for doing this.
A couple comments here:
1.
-riscv_init_cumulative_args (CUMULATIVE_ARGS *cum,
- tree fntype ATTRIBUTE_UNUSED,
- rtx libname ATTRIBUTE_UNUSED,
- tree fndecl,
+riscv_init_cumulative_args
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Sunday, June 25, 2023 8:57 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; pal...@dabbelt.com;
pal...@rivosinc.com;
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Sunday, June 25, 2023 8:53 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; pal...@dabbelt.com;
pal...@rivosinc.com;
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Sunday, June 25, 2023 8:48 PM
To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org
Cc: richard.sandif...@arm.com; rguent...@suse.de
Subject: Re: [PATCH] internal-fn: Fix bug of
On 6/20/23 03:40, Fei Gao wrote:
gcc/ChangeLog:
* shrink-wrap.cc (try_shrink_wrapping_separate):call
use_shrink_wrapping_separate.
(use_shrink_wrapping_separate): wrap the condition
check in use_shrink_wrapping_separate.
* shrink-wrap.h
On 25.06.2023 09:30, Hongtao Liu wrote:
> On Sun, Jun 25, 2023 at 3:23 PM Hongtao Liu wrote:
>>
>> On Sun, Jun 25, 2023 at 3:13 PM Hongtao Liu wrote:
>>>
>>> On Sun, Jun 25, 2023 at 1:52 PM Jan Beulich wrote:
On 25.06.2023 06:42, Hongtao Liu wrote:
> On Wed, Jun 21, 2023 at 2:26
Ping. With RISCV tag this time.
Forwarded Message
Subject: [PR target/110201] Fix operand types for various scalar crypto
insns
Date: Mon, 19 Jun 2023 16:34:28 -0600
From: Jeff Law
To: gcc-patches@gcc.gnu.org
A handful of the scalar crypto instructions are supposed to
On 6/22/23 05:11, Philipp Tomsich wrote:
From: Manolis Tsamis
Fixes: 6a2e8dcbbd4bab3
Propagation for the stack pointer in regcprop was enabled in
6a2e8dcbbd4bab3, but set ORIGINAL_REGNO/REG_ATTRS/REG_POINTER for
stack_pointer_rtx which caused regression (e.g., PR 110313, PR 110308).
This
On 6/25/23 06:20, Juzhe-Zhong wrote:
This patch is depending on LEN_MASK_{LOAD,STORE} patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622742.html
After enabling the LEN_MASK_{LOAD,STORE}, I notice that there is a case that
VSETVL PASS need to be optimized:
void
f (int32_t
On 6/25/23 03:13, juzhe.zh...@rivai.ai wrote:
LGTM.
Thanks for fixing it.
Agreed. I didn't see the V2 had already been posted.
Hi, Jeff:
I saw Li Xu is frequently helping RVV support in GCC. Is it possible to
give him the write access?
Yes, we can do that with the normal process.
Li
On 6/25/23 02:39, Juzhe-Zhong wrote:
This patch enable len_mask_{load,store} to support flow-control in RVV
auto-vectorization.
Consider this following case:
void
f (int32_t *__restrict a,
int32_t *__restrict b,
int32_t *__restrict cond,
int n)
{
for (int i = 0; i < n; i++)
On 6/24/23 21:43, juzhe.zh...@rivai.ai wrote:
Hi, Li.
Appreciate for catching this!
I think it's better:
-emit_insn (gen_rtx_SET (gen_lowpart (e.vector_mode (), e.target), src));
+emit_move_insn (gen_lowpart (e.vector_mode (), e.target), src);
do this to fix this issue.
Agreed. Assuming a
On 6/24/23 19:40, Stefan O'Rear wrote:
On Sat, Jun 24, 2023, at 11:01 AM, Jeff Law via Gcc-patches wrote:
On 6/21/23 02:14, Wang, Yanzhang wrote:
Hi Jeff, sorry for the late reply.
The long branch handling is done at the assembler level. So the clobbering
of $ra isn't visible to the
On 6/24/23 21:36, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
When trying to enable LEN_MASK_{LOAD,STORE} in RISC-V port,
I found I made a mistake in case of argument index of BIAS.
This patch is an obvious fix,
Ok for trunk ?
gcc/ChangeLog:
* internal-fn.cc
This patch adds an experimental vector calling convention proposal that the
user can enable with --param=riscv-vector-abi option. The details of this
proposal can be viewed at this link:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/389 . Please help me
to review this proposal, thank
This patch is depending on LEN_MASK_{LOAD,STORE} patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622742.html
After enabling the LEN_MASK_{LOAD,STORE}, I notice that there is a case that
VSETVL PASS need to be optimized:
void
f (int32_t *__restrict a,
int32_t *__restrict b,
Tested on various affected Darwin versions and on x86_64-linux-gnu
OK for trunk?
OK for 13.2?
thanks
Iain
--- 8< ---
When we make a select() that fails, there is an attempt to (a) diagnose
why and (b) make a fallback. These actions are causing some tests to
hang on some Darwin versions, this is
ChangeLog:
* MAINTAINERS: Add Lehua Ding to write after approval
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4825ee449ae..bac773ad0af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -394,6 +394,7 @@ Chris Demetriou
Tested on i686, powerpc, x86_64 and aarch64 darwin (for versions requiring
PIE and also some that default to non-PIE). Also tested on x86_64-linux-gnu
with and without --enable-host-pie.
pushed to master, thanks
Iain
--- 8< ---
The latest versions of Darwin on the Aarch64 platform mandate
LGTM.
Thanks for fixing it.
Hi, Jeff:
I saw Li Xu is frequently helping RVV support in GCC. Is it possible to give
him the write access?
Thanks.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-06-25 17:09
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; zhengyu; Li Xu
Subject: [PATCH v2]
Consider this following case:
void test_vlmul_ext_v_i8mf8_i8mf4(vint8mf8_t op1) {
vint8mf4_t res = __riscv_vlmul_ext_v_i8mf8_i8mf4(op1);
}
Compilation fails with:
test.c: In function 'test_vlmul_ext_v_i8mf8_i8mf4':
test.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 30 29 0 2 (set
This patch enable len_mask_{load,store} to support flow-control in RVV
auto-vectorization.
Consider this following case:
void
f (int32_t *__restrict a,
int32_t *__restrict b,
int32_t *__restrict cond,
int n)
{
for (int i = 0; i < n; i++)
if (cond[i])
a[i] = b[i];
}
Before
This patch enable len_mask_{load,store} to support flow-control in RVV
auto-vectorization.
Consider this following case:
void
f (int32_t *__restrict a,
int32_t *__restrict b,
int32_t *__restrict cond,
int n)
{
for (int i = 0; i < n; i++)
if (cond[i])
a[i] = b[i];
}
Before
On Sat, Jun 24, 2023 at 8:04 PM Roger Sayle wrote:
>
>
> This patch contains a pair of (related) optimizations in i386.md that
> allow us to generate better code for the example below (this is a step
> towards fixing a bugzilla PR, but I've forgotten the number).
>
> __int128 foo64(__int128 x,
Sure, reverted and will commit this patch after the issue addressed.
Pan
-Original Message-
From: Andreas Schwab
Sent: Sunday, June 25, 2023 3:22 PM
To: juzhe.zh...@rivai.ai
Cc: yulong ; gcc-patches ;
palmer ; Kito.cheng ; Jim Wilson
; Li, Pan2 ; wuwei2016
; jiawei ; shihua
;
On Sun, Jun 25, 2023 at 3:23 PM Hongtao Liu wrote:
>
> On Sun, Jun 25, 2023 at 3:13 PM Hongtao Liu wrote:
> >
> > On Sun, Jun 25, 2023 at 1:52 PM Jan Beulich wrote:
> > >
> > > On 25.06.2023 06:42, Hongtao Liu wrote:
> > > > On Wed, Jun 21, 2023 at 2:26 PM Jan Beulich via Gcc-patches
> > > >
On Sun, Jun 25, 2023 at 3:13 PM Hongtao Liu wrote:
>
> On Sun, Jun 25, 2023 at 1:52 PM Jan Beulich wrote:
> >
> > On 25.06.2023 06:42, Hongtao Liu wrote:
> > > On Wed, Jun 21, 2023 at 2:26 PM Jan Beulich via Gcc-patches
> > > wrote:
> > >>
> > >> +(define_code_iterator andor [and ior])
> > >>
Please revert until bootstrap is restored.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Sun, Jun 25, 2023 at 1:52 PM Jan Beulich wrote:
>
> On 25.06.2023 06:42, Hongtao Liu wrote:
> > On Wed, Jun 21, 2023 at 2:26 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> +(define_code_iterator andor [and ior])
> >> +(define_code_attr nlogic [(and "nor") (ior "nand")])
> >>
On Sun, Jun 25, 2023 at 2:35 PM Hongtao Liu wrote:
>
> On Sun, Jun 25, 2023 at 2:25 PM Jan Beulich wrote:
> >
> > On 25.06.2023 07:12, Hongtao Liu wrote:
> > > On Wed, Jun 21, 2023 at 2:29 PM Jan Beulich via Gcc-patches
> > > wrote:
> > >>
> > >> ---
> > >> For the purpose here (and elsewhere)
On Sun, Jun 25, 2023 at 2:25 PM Jan Beulich wrote:
>
> On 25.06.2023 07:12, Hongtao Liu wrote:
> > On Wed, Jun 21, 2023 at 2:29 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> ---
> >> For the purpose here (and elsewhere) bcst_vector_operand() (really:
> >> bcst_mem_operand()) isn't
On Sun, Jun 25, 2023 at 2:16 PM Jan Beulich wrote:
>
> On 25.06.2023 07:06, Hongtao Liu wrote:
> > On Wed, Jun 21, 2023 at 2:28 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> With respective two-operand bitwise operations now expressable by a
> >> single VPTERNLOG, add splitters to also
On 25.06.2023 07:12, Hongtao Liu wrote:
> On Wed, Jun 21, 2023 at 2:29 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> ---
>> For the purpose here (and elsewhere) bcst_vector_operand() (really:
>> bcst_mem_operand()) isn't permissive enough: We'd want it to allow
>> 128-bit and 256-bit types as
On 25.06.2023 07:06, Hongtao Liu wrote:
> On Wed, Jun 21, 2023 at 2:28 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> With respective two-operand bitwise operations now expressable by a
>> single VPTERNLOG, add splitters to also deal with ior and xor
>> counterparts of the original and-only case.
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Saturday, June 24, 2023 10:45 PM
To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org
Cc: rguent...@suse.de; richard.sandif...@arm.com
Subject: Re: [PATCH] GIMPLE_FOLD: Apply
59 matches
Mail list logo
