Hi,
on 2023/5/4 21:25, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> This patch is fixing V3 patch:
> https://patchwork.sourceware.org/project/gcc/patch/20230407014741.139387-1-juzhe.zh...@rivai.ai/
>
> Fix issues according to Richard Sandiford && Richard Biener.
>
> 1. Rename
This patch adds the support for match that was implemented for PR 87913 in
phiopt.
It implements it by adding support to minmax_from_comparison for the check.
It uses the range information if available which allows to produce MIN/MAX
expression
when comparing against the lower/upper bound of the
From: Juzhe-Zhong
1. Add movmisalign pattern for TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
targethook, current RISC-V has supported this target hook, we can't make
it supported without movmisalign pattern.
2. Remove global extern of get_mask_policy_no_pred && get_tail_policy_no_pred.
diff --git a/gcc/config/riscv/zc.md b/gcc/config/riscv/zc.md
new file mode 100644
index 000..1c2f390269e
--- /dev/null
+++ b/gcc/config/riscv/zc.md
@@ -0,0 +1,55 @@
...
+(define_insn "gpr_multi_pop"
+ [(unspec_volatile [(match_operand 0 "const_int_operand")
+
shrink-wraping already gated by Os so I think we don't need add more
gate here, unless we are trying to claim force optimize for size if
zcmp is present.
On Sat, May 6, 2023 at 4:41 PM Fei Gao wrote:
>
> zcmp aims to reduce code size, while shrink-wrap-separate prefers
> speed to code size. So
> > @@ -4799,7 +4800,8 @@ vect_create_vectorized_demotion_stmts (vec_info
> > *vinfo, vec *vec_oprnds,
> >stmt_vec_info stmt_info,
> >vec _dsts,
> >gimple_stmt_iterator *gsi,
>
Update the X86 memory bytes allocated by below changes (included kito's patch
for the tree common part).
rtx_def code 16 => 12 bits.
rtx_def mode 8 => 12 bits.
tree_base code 16 => 12 bits.
Bytes allocated with O2:
Gentle ping this patch.
Is this Ok for trunk? Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-05-06 19:14
To: gcc-patches
CC: kito.cheng; Juzhe-Zhong
Subject: [PATCH] RISC-V: Optimize vsetvli of LCM INSERTED edge for user vsetvli
[PR 109743]
From: Juzhe-Zhong
This patch is
I see. Thank you, will have a try soon.
Pan
-Original Message-
From: Jeff Law
Sent: Sunday, May 7, 2023 11:24 PM
To: Li, Pan2 ; Kito Cheng
Cc: juzhe.zh...@rivai.ai; rguenther ; richard.sandiford
; gcc-patches ; palmer
; jakub
Subject: Re: [PATCH] machine_mode type size: Extend enum
Harald,
Thanks for keeping us honest. I didn't check what other
separators might cause a problem.
After 2 decades of working on gfortran, I've come to conclusion
that -std=f2018 should be the default. When f2023 is ratified,
the default becomes -std=f2023. All GNU fortran extension
should be
This patch adds the scheduling model for Neoverse V1, based on the information
from the “Arm Neoverse V1 Software Optimization Guide” and on static and
dynamic analysis of internal and public benchmarks. Results are forthcoming.
--
Evandro Menezes
This moves the `a <= CST1 ? MAX : a` optimization
from phiopt to match. It just adds a new pattern to match.pd.
There is one more change needed before being able to remove
minmax_replacement from phiopt.
A few notes on the testsuite changes:
* phi-opt-5.c is now able to optimize at phiopt1 so
>> It's been pretty standard to stick with just PLUS_EXPR for this stuff
>> and instead negate the constant to produce the same effect as
>> MINUS_EXPR. Is there a reason we're not continuing that practice?
>> Sorry if you've answered this already -- if you have, you can just point
>> me at the
aarch64_isa_flags (and aarch64_asm_isa_flags) are both aarch64_feature_flags
(uint64_t)
but since r12-8000-g14814e20161d, they are saved/restored as unsigned long. This
does not make a difference for LP64 targets but on ILP32 and LLP64IL32 targets,
it means it does not get restored correctly.
On Sun, 7 May 2023, Jiaxun Yang wrote:
> > Both EHB and J[AL]R.HB are backwards compatible however (except for an
> > obscure 4Kc J[AL]R.HB erratum I came across once and which may be no
> > longer relevant), so I think the legacy sequence ought to just return via
> > JR.HB as well, therefore
> 2023年5月7日 18:34，Maciej W. Rozycki 写道：
>
> On Wed, 3 May 2023, Jiaxun Yang wrote:
>
>> Since it’s possible to run R2- binary on R2+ processor, we’d better find a
>> semantic that do eliminate speculation on all processors. While SSNOPs
>> on R2+ processors is pretty much undefined, there is
Hi Jerry,
I've made a small compiler survey how they behave on namelist read
from an internal unit when:
1.) there is a single input line of the type
"" // testchar // " n = 666/"
2.) the input spans 2 lines split after the testchar
3.) same as 2.) but first line right-adjusted
See attached
On Wed, 3 May 2023, Jiaxun Yang wrote:
> Since it’s possible to run R2- binary on R2+ processor, we’d better find a
> semantic that do eliminate speculation on all processors. While SSNOPs
> on R2+ processors is pretty much undefined, there is no guarantee that
> SSNOP sequence can eliminate
On 5/6/23 11:15 AM, Harald Anlauf via Fortran wrote:
Hi Jerry, Steve,
I think I have to pour a little water into the wine.
The patch fixes the reported issue only for a comma after
the namelist name, but we still accept a few other illegal
characters, e.g. ';', because:
#define
aarch64_isa_flags (and aarch64_asm_isa_flags) are both aarch64_feature_flags
(uint64_t)
but since r12-8000-g14814e20161d, they are saved/restored as unsigned long. This
does not make a difference for LP64 targets but on ILP32 and LLP64IL32 targets,
it means it does not get restored correctly.
On 5/6/23 19:55, Li, Pan2 wrote:
It looks like we cannot simply swap the code and mode in rtx_def, the code may
have to be the same bits as the tree_code in tree_base. Or we will meet ICE
like below.
rtx_def code 16 => 8 bits.
rtx_def mode 8 => 16 bits.
static inline decl_or_value
On Sat, May 6, 2023 at 4:00 PM Roger Sayle wrote:
>
>
> Hi Uros,
> This is a repost/respin of a patch that was conditionally approved:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609470.html
>
> This patch adds a convenient post-reload splitter for setting/updating
> the highpart of
On 5/4/23 07:25, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
This patch is fixing V3 patch:
https://patchwork.sourceware.org/project/gcc/patch/20230407014741.139387-1-juzhe.zh...@rivai.ai/
Fix issues according to Richard Sandiford && Richard Biener.
1. Rename WHILE_LEN pattern into
Hi,
On 2023-04-26 17:35, Kewen.Lin wrote:
Hi Jeff,
on 2023/1/4 14:51, Jiufu Guo wrote:
Hi,
Compare with previous version, this patch updates the comments only.
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608293.html
For a complicate 64bit constant, below is one
Pushed.
Gerald
---
Commit 7c0b3155efaecf8c9bfa5192ca99acc7356bec71 for GCC 13.1 "stole" an
opening from the existing GCC 13.2 entry.
---
htdocs/onlinedocs/index.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
index
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Russian team of translators. The file is available at:
https://translationproject.org/latest/cpplib/ru.po
(This file,
cpplib-13.1-b20230212.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
27 matches
Mail list logo
