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 421d1d0b..
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 instruction-sequen
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 SELE
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 a
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
dv_from_
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.
This
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 is_separator(c)
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 specu
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
"&stuff" // testchar // " n = 666/"
2.) the input spans 2 lines split after the testchar
3.) same as 2.) but first line right-adjusted
See atta
> 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
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 p
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.
This
>> 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 pr
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 rem
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
0001-aarch64-Add-scheduling-model-for-Neove
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
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
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 fixing
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:
-
> > @@ -4799,7 +4800,8 @@ vect_create_vectorized_demotion_stmts (vec_info
> > *vinfo, vec *vec_oprnds,
> >stmt_vec_info stmt_info,
> >vec &vec_dsts,
> >gimple_stmt_iterator *gsi,
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 di
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")
+ (match_ope
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.
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
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 WHILE_LEN
On Mon, 17 Apr 2023 15:18:27 -0700
Steve Kargl wrote:
> On Mon, Apr 17, 2023 at 09:47:50PM +0200, Bernhard Reutner-Fischer via
> Fortran wrote:
> > On Mon, 03 Apr 2023 23:42:06 +0200
> > Bernhard Reutner-Fischer wrote:
> >
> > > On 3 April 2023 21:50:49 CEST, Harald Anlauf wrote:
> > > >Hi
On Wed, 1 Mar 2023 16:07:14 -0800
Steve Kargl wrote:
> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via
> Fortran wrote:
> > libgfortran/caf/single.c |6 ++
> > libgfortran/io/async.c |6 ++
> > libgfortran/io/format.c |3 +--
> > libgfor
On Fri, May 5, 2023 at 5:18 PM 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 statement was
> "dead" a
Hi Haochen,
on 2023/1/4 14:16, HAO CHEN GUI wrote:
> Hi,
> This patch changes the return type of __builtin_vsx_scalar_extract_exp
> from const signed long to const signed int, as the exponent can be put in
> a signed int. It is also inline with the external interface definition of
> the bif. The
On Fri, 5 May 2023, Alexander Monakov wrote:
> > > gimple-head-export.cc does not exist.
> > >
> > > gimple-match-exports.cc is not a generated file. It's under source
> > > control and
> > > edited independently from genmatch.cc. It is compiled separately,
> > > producing
> > > gimple-match-ex
On Fri, 5 May 2023, Jakub Jelinek wrote:
> On Fri, May 05, 2023 at 01:32:02PM -0400, Jason Merrill wrote:
> > > --- gcc/ada/gcc-interface/utils2.cc.jj2023-01-16 23:19:05.539727388
> > > +0100
> > > +++ gcc/ada/gcc-interface/utils2.cc 2023-05-05 15:37:30.193990948
> > > +0200
> > > @@ -
Hi, Kewen.>> Sorry for chiming in, I had some concern here.
>> We already have some handlings for partial vector in length in
>> vect_set_loop_controls_directly
>>(actually it deals with both mask and length), the proposed
>>vect_set_loop_controls_by_select_vl
>>for select_vl looks like a variant
On Sun, 7 May 2023, Jeff Law wrote:
>
>
> 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.
> > rt
Hi Haochen,
on 2023/1/4 14:16, HAO CHEN GUI wrote:
> Hi,
> This patch changes the return type of __builtin_vsx_scalar_extract_sig
> from const signed long to const signed long long, so that it can be called
> with "-m32/-mpowerpc64" option. The bif needs TARGET_POWERPC64 instead of
> TARGET_64BI
Hi Haochen,
on 2023/1/4 14:17, HAO CHEN GUI wrote:
> Hi,
> This patch changes the mode of exponent to GPR in scalar insert exp
> pattern, as the exponent can be put into a 32-bit register. Also the
> condition check is changed from TARGET_64BIT to TARGET_POWERPC64.
>
> The test cases are modi
Hi Haochen,
on 2023/1/4 14:17, HAO CHEN GUI wrote:
> Hi,
> "ilp32" is used in these test cases to make sure test cases only run on a
> 32-bit environment. Unfortunately, these cases also run with
> "-m32/-mpowerpc64" which causes unexpected errors. This patch changes the
> target check to skip i
Oops. Actually I am patching a version as you mentioned like storage
allocation. Thank you Richard, will try your suggestion and keep you posted.
Pan
-Original Message-
From: Richard Biener
Sent: Monday, May 8, 2023 2:30 PM
To: Jeff Law
Cc: Li, Pan2 ; Kito Cheng ;
juzhe.zh...@rivai.a
On Sat, May 6, 2023 at 8:46 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/6/23 06:57, Roger Sayle wrote:
> >
> > Following up on posts/reviews by Segher and Uros, there's some question
> > over why the middle-end's lower subreg pass emits a clobber (of a
> > multi-word register) into the instruc
On Sun, May 7, 2023 at 6:44 AM Andrew Pinski via Gcc-patches
wrote:
>
> After using factor_out_conditional_conversion with diamond bb,
> we should be able do use it also for all normal unary gimple and not
> just conversions. This allows to optimize PR 59424 for an example.
> This is also a start
On Sun, May 7, 2023 at 6:45 AM Andrew Pinski via Gcc-patches
wrote:
>
> After adding diamond shaped bb support to factor_out_conditional_conversion,
> we can get a case where we have two conversions that needs factored out
> and then would have another phiopt happen.
> An example is:
> ```
> stati
On Sun, May 7, 2023 at 7:05 AM Andrew Pinski via Gcc-patches
wrote:
>
> So the function factor_out_conditional_conversion already supports
> diamond shaped bb forms, just need to be called for such a thing.
>
> harden-cond-comp.c needed to be changed as we would optimize out the
> conversion now a
On Mon, May 8, 2023 at 8:51 AM Richard Biener
wrote:
>
> On Sun, May 7, 2023 at 7:05 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > So the function factor_out_conditional_conversion already supports
> > diamond shaped bb forms, just need to be called for such a thing.
> >
> > harden-cond-comp.
42 matches
Mail list logo
