From: Ju-Zhe Zhong
Since 'add_lable_notes' is a generic helper function which is used by
riscv-vsetvl.cc
in RISC-V port backend. And it's also will be used by riscv.cc too by the
following patches.
Export it as global helper function.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (add
On Fri, 7 Jul 2023, Jan Hubicka wrote:
> >
> > Looks good, but I wonder what we can do to at least make the
> > multiple exit case behave reasonably? The vectorizer keeps track
>
> > of a "canonical" exit, would it be possible to pass in the main
> > exit edge and use that instead of single_exi
On Mon, 10 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Since 'add_lable_notes' is a generic helper function which is used by
> riscv-vsetvl.cc
> in RISC-V port backend. And it's also will be used by riscv.cc too by the
> following patches.
> Export it as global helper functi
On Fri, Jul 7, 2023 at 7:57 PM Andrew Pinski via Gcc-patches
wrote:
>
> When I moved two_value to match.pd, I removed the check for the {0,+-1}
> as I had placed it after the {0,+-1} case for cond in match.pd.
> In the case of {0,+-1} and non boolean, before we would optmize those
> case to just `
From: Ju-Zhe Zhong
Since VSETVL PASS in RISC-V port is using common part of
'insert_insn_end_basic_block (struct gcse_expr *expr, basic_block bb)'
and we will also this helper function in riscv.cc for the following patches.
So extract the common part codes of 'insert_insn_end_basic_block (struc
Hi, Richard.
I find out I just only need to export 'insert_insn_end_basic_block' for global
used by RISC-V port (current riscv-vsetvl.cc and future riscv.cc).
Does it look more reasonable ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-10 15:25
To: Ju-Zhe Zhong
CC: gcc-pat
Sorry, I forget to add the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623960.html
juzhe.zh...@rivai.ai
From: juzhe.zh...@rivai.ai
Date: 2023-07-10 15:58
To: rguenther
CC: gcc-patches; jeffreyalaw
Subject: Re: Re: [PATCH] GCSE: Export add_label_notes as global function
Hi, Ric
On Mon, 10 Jul 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richard.
>
> I find out I just only need to export 'insert_insn_end_basic_block' for
> global used by RISC-V port (current riscv-vsetvl.cc and future riscv.cc).
>
> Does it look more reasonable ?
Yes, it looks more reasonable - I'll leave
From: Ju-Zhe Zhong
Since VSETVL PASS in RISC-V port is using common part of
'insert_insn_end_basic_block (struct gcse_expr *expr, basic_block bb)'
and we will also this helper function in riscv.cc for the following patches.
So extract the common part codes of 'insert_insn_end_basic_block (struc
Thanks Richi.
I have sent V2 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623964.html
which is fixing the comments for you:
-/* Add EXPR to the end of basic block BB.
-
- This is used by both the PRE and code hoisting. */
+/* Return the INSN which is added at the end of the bloc
Hi,
over weekend I found that vectorizer is missing scale_loop_profile for
epilogues. It already adjusts loop_info to set max iteraitons, so
adding it was easy. However now predicts the first loop to iterate at
most once (which is too much, I suppose it forgets to divide by epilogue
unrolling fact
On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
wrote:
>
> As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
>
> (gdb) list
> 469 if (code == SUBREG)
> 470 {
> 471 op0 = simplify_replace_fn_rtx (SUBREG_REG (x),
> old_rtx, fn, d
> On Fri, 7 Jul 2023, Jan Hubicka wrote:
>
> > >
> > > Looks good, but I wonder what we can do to at least make the
> > > multiple exit case behave reasonably? The vectorizer keeps track
> >
> > > of a "canonical" exit, would it be possible to pass in the main
> > > exit edge and use that inste
On Mon, 10 Jul 2023, Jan Hubicka wrote:
> Hi,
> over weekend I found that vectorizer is missing scale_loop_profile for
> epilogues. It already adjusts loop_info to set max iteraitons, so
> adding it was easy. However now predicts the first loop to iterate at
> most once (which is too much, I supp
On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
wrote:
>
> On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> wrote:
> >
> > As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
> >
> > (gdb) list
> > 469 if (code == SUBREG)
> > 470 {
> > 471
On Mon, 10 Jul 2023, Jan Hubicka wrote:
> > On Fri, 7 Jul 2023, Jan Hubicka wrote:
> >
> > > >
> > > > Looks good, but I wonder what we can do to at least make the
> > > > multiple exit case behave reasonably? The vectorizer keeps track
> > >
> > > > of a "canonical" exit, would it be possible
On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
>
> On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> wrote:
> >
> > On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> > wrote:
> > >
> > > As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
> > >
> > > (gdb) l
On Fri, Jul 7, 2023 at 5:14 PM H.J. Lu via Gcc-patches
wrote:
>
> Don't assume that stack slots can only be accessed by stack or frame
> registers. We first find all registers defined by stack or frame
> registers. Then check memory accesses by such registers, including
> stack and frame registe
On Fri, 7 Jul 2023, Xi Ruoyao wrote:
> If a bit-field is signed and it's wider than the output type, we must
> ensure the extracted result sign-extended. But this was not handled
> correctly.
>
> For example:
>
> int x : 8;
> long y : 55;
> bool z : 1;
>
> The vectorized extraction
On Fri, 7 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richard and Richi.
>
> This patch is adding cond_len_* operations pattern for target support
> loop control with length.
It looks mostly OK - the probably obvious question is with rearding
to the "missing" bias argum
On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
wrote:
>
> On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
> >
> > On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> > wrote:
> > >
> > > On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> > > wrote:
> > > >
> > > > As shown in the
On Mon, 2023-07-10 at 10:33 +, Richard Biener wrote:
> On Fri, 7 Jul 2023, Xi Ruoyao wrote:
>
> > If a bit-field is signed and it's wider than the output type, we
> > must
> > ensure the extracted result sign-extended. But this was not handled
> > correctly.
> >
> > For example:
> >
> >
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch is adding cond_len_* operations pattern for target support loop
control with length.
These patterns will be used in these following case:
1. Integer division:
void
f (int32_t *restrict a, int32_t *restrict b, int32_t *restrict c, int
Thanks Richi.
I added "BIAS" for you:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623978.html
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-10 18:40
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford; linkw; krebbel
Subject: Re: [PATCH] VECT: Add COND_LEN_* operati
On Mon, Jul 10, 2023 at 1:01 PM Uros Bizjak wrote:
>
> On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
> wrote:
> >
> > On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
> > >
> > > On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> > > wrote:
> > > >
> > > > On Sun, Jul 9, 2023 at 10:53 AM Ur
From: Alexandre Oliva
Document leafy mode.
gcc/ada/
* doc/gnat_rm/security_hardening_features.rst (Register
Scrubbing): Document leafy mode.
* gnat_rm.texi: Regenerate.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/doc/gnat_rm/security_hardening_feat
From: Yannick Moy
CodePeer is correctly warning on a test always true in an assertion.
It can be rewritten without loss of proof to avoid that message.
gcc/ada/
* libgnat/s-aridou.adb (Lemma_Powers_Of_2_Commutation): Rewrite
assertion.
Tested on x86_64-pc-linux-gnu, committed o
From: Eric Botcazou
It turns out that adaint.c includes other Windows header files than just
windows.h, so defining WIN32_LEAN_AND_MEAN is not sufficient for it.
gcc/ada/
* adaint.c [_WIN32]: Undefine 'abort' macro.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/adai
From: Yannick Moy
The proof of System.Arith_Double still required the use of
CVC4, now replaced by its successor cvc5. Adapt the proof to be
able to remove CVC4 in the proof of run-time units.
gcc/ada/
* libgnat/s-aridou.adb (Lemma_Div_Mult): New simple lemma.
(Lemma_Powers_Of_2
From: Tom Tromey
A future patch will change sname.h-tmpl to use enums rather than
preprocessor defines. In order to do this, first introduce some
typedefs that can be used in gcc-interface.
gcc/ada/
* snames.h-tmpl (Name_Id, Attribute_Id, Convention_Id)
(Pragma_Id): New typedef
From: Alexandre Oliva
Adjust documentation to reflect the introduction of
-fhardcfr-check-noreturn-calls=no-xthrow.
gcc/ada/
* doc/gnat_rm/security_hardening_features.rst (Control Flow
Redundancy): Add -fhardcfr-check-noreturn-calls=no-xthrow.
* gnat_rm.texi: Regenerate.
From: Alexandre Oliva
Document -fhardcfr-skip-leaf.
gcc/ada/
* doc/gnat_rm/security_hardening_features.rst (Control Flow
Hardening): Document -fhardcfr-skip-leaf.
* gnat_rm.texi: Regenerate.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/doc/gnat_rm/s
From: Bob Duff
This patch documents the new feature that allows declarations mixed with
statements, primarily by referring to the RFC.
gcc/ada/
* doc/gnat_rm/gnat_language_extensions.rst
(Local Declarations Without Block): Document the feature very
briefly, and refer the
On Wed, 28 Jun 2023 at 08:56, Jan Hubicka wrote:
>
> > I think the __throw_bad_alloc() and __throw_bad_array_new_length()
> > functions should always be rare, so marking them cold seems fine (users who
> > define their own allocators that want to throw bad_alloc "often" will
> > probably throw it
After the recent MVE intrinsics re-implementation, LTO stopped working
because the intrinsics would no longer be defined.
The main part of the patch is simple and similar to what we do for
AArch64:
- call handle_arm_mve_h() from arm_init_mve_builtins to declare the
intrinsics when the compiler i
> -Original Message-
> From: Christophe Lyon
> Sent: Friday, July 7, 2023 8:52 AM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw
> Cc: Christophe Lyon
> Subject: [PATCH] testsuite: Add _link flavor for several arm_arch* and arm*
> effective-targets
>
> For arm tar
> -Original Message-
> From: Christophe Lyon
> Sent: Friday, July 7, 2023 8:52 AM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw
> Cc: Christophe Lyon
> Subject: [PATCH] doc: Document arm_v8_1m_main_cde_mve_fp
>
> The arm_v8_1m_main_cde_mve_fp family of effective
> -Original Message-
> From: Christophe Lyon
> Sent: Monday, July 10, 2023 2:09 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw
> Cc: Christophe Lyon
> Subject: [PATCH v2] arm: Fix MVE intrinsics support with LTO (PR
> target/110268)
>
> After the recent MVE int
On Mon, 10 Jul 2023 at 15:46, Kyrylo Tkachov wrote:
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Friday, July 7, 2023 8:52 AM
> > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> > Richard Earnshaw
> > Cc: Christophe Lyon
> > Subject: [PATCH] testsuite: Add _link flavo
> -Original Message-
> From: Christophe Lyon
> Sent: Monday, July 10, 2023 2:59 PM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
>
> Subject: Re: [PATCH] testsuite: Add _link flavor for several arm_arch* and
> arm* effective-targets
>
>
>
> On Mon, 10 Jul 2023
On 7/10/23 02:12, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
Since VSETVL PASS in RISC-V port is using common part of
'insert_insn_end_basic_block (struct gcse_expr *expr, basic_block bb)'
and we will also this helper function in riscv.cc for the following patches.
So extract the commo
Document `z` and `i` operand modifiers, we have much more modifiers
other than those two, but they are the only two implement on both
GCC and LLVM, consider the compatibility I would like to document those
two first, and then review other modifiers later to see if any other should
expose and implem
On 7/10/23 08:19, Kito Cheng wrote:
Document `z` and `i` operand modifiers, we have much more modifiers
other than those two, but they are the only two implement on both
GCC and LLVM, consider the compatibility I would like to document those
two first, and then review other modifiers later to
thanks, pushed to trunk :)
On Mon, Jul 10, 2023 at 10:33 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 7/10/23 08:19, Kito Cheng wrote:
> > Document `z` and `i` operand modifiers, we have much more modifiers
> > other than those two, but they are the only two implement on both
> > GCC and LLVM, c
Tested on x86_64-pc-linux-gnu, pushed to trunk as obvious.
-- >8 --
Now that we cache level-lowered ttps we can end up processing the same
ttp multiple times via (multiple calls to) redeclare_class_template, so
we can't assume a ttp's DECL_CONTEXT is initially empty.
PR c++/110523
gcc/c
Committed, thanks Jeff and Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Monday, July 10, 2023 10:08 PM
To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org
Cc: rguent...@suse.de
Subject: Re: [PATCH v2] GCSE: Export 'insert_insn_end_basic_blo
> > - *type_out = STMT_VINFO_VECTYPE (stmt_info);
> > + if (cond_cst)
> > +{
> > + append_pattern_def_seq (vinfo, stmt_info, pattern_stmt, vectype);
> > + pattern_stmt
> > + = gimple_build_cond (gimple_cond_code (cond_stmt),
> > +gimple_get_lhs (pattern_stm
Hi all,
while browsing the pdt meta-bug I came across 102003 and thought to myself:
Well, that one is easy. How foolish of me...
Anyway, the solution attached prevents a pdt_len (or pdt_kind) expression in a
function call (e.g. len() or kind()) to mark the whole expression as a pdt one.
The secon
Hello,
the ELF psABI for x86-64 doesn't have any callee-saved SSE
registers (there were actual reasons for that, but those don't
matter anymore). This starts to hurt some uses, as it means that
as soon as you have a call (say to memmove/memcpy, even if
implicit as libcall) in a loop that manipula
On Mon, 10 Jul 2023, liuhongt via Gcc-patches wrote:
> False dependency happens when destination is only updated by
> pternlog. There is no false dependency when destination is also used
> in source. So either a pxor should be inserted, or input operand
> should be set with constraint '0'.
>
>
While helping someone on the team debug an issue, I noticed some redundant
tests in a couple of our predicates which can be removed. I'm going to
commit the following as obvious once bootstrap and regtesting come back
clean.
Peter
rs6000: Remove redundant MEM_P predicate usage
The quad_memory_
> Am 10.07.2023 um 17:56 schrieb Michael Matz via Gcc-patches
> :
>
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you ha
Hi Thomas,
this patch contains support for the 'readonly' modifier in copyin clauses
and the cache directive.
As we discussed earlier, the work for actually linking this to middle-end
points-to analysis is a somewhat non-trivial issue. This first patch allows
the language feature to be used in Ope
Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path
in find_fde_tail").
libgcc/
PR libgcc/110179
* unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid
implicit conversion of pointer value to integer.
---
libgcc/unwind-dw2-fde-dip.c | 2 +-
1 file c
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type pdt(n)
integer, len :: n = 8
character(len=n) :: c
end type pdt
type(pdt(42)) :: p
integer, parameter ::
On Mon, 10 Jul 2023, Michael Matz via Gcc-patches wrote:
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you have a call (say
Hi,
This is the change for the GCC14 releaes Notes on the deprecating of a C
extension about flexible array members.
Okay for committing?
thanks.
Qing
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
extension about flexible array members.
---
htdocs/gcc-14/ch
On Thu, 2023-07-06 at 17:54 -0500, Peter Bergner wrote:
> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
> > rs6000, __builtin_set_fpscr_rn add retrun value
>
> s/retrun/return/
>
> Maybe better written as:
>
> rs6000: Add return value to __builtin_set_fpscr_rn
Changed subject, fixed miss
On Fri, 2023-07-07 at 12:06 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> Some more minor comments are inline below on top of Peter's
> insightful
> review comments.
>
> on 2023/7/1 08:58, Carl Love wrote:
> > GCC maintainers:
> >
> > Ver 2, Went back thru the requirements and emails. Not sure where
GCC maintainers:
Ver 3, Renamed the patch per comments on ver 2. Previous subject line
was " [PATCH ver 2] rs6000, __builtin_set_fpscr_rn add retrun value".
Fixed spelling mistakes and formatting. Updated define_expand
"rs6000_set_fpscr_rn to have the rs6000_get_fpscr_fields and
rs6000_updat
On Mon, Jul 10, 2023 at 08:54:54PM +0200, Florian Weimer via Gcc-patches wrote:
> Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path
> in find_fde_tail").
>
> libgcc/
>
> PR libgcc/110179
> * unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid
> implicit
Hi Harald,
I do get why this happens. I still don't get why I have to do this
'optimization' manually. I mean, this rewriting of expressions is needed in
more than one location and most probably already present somewhere. So who
can point me in the right direction?
Regards,
Andre
Andre Vehresch
On Sat, 1 Jul 2023, Nathaniel Shead wrote:
> This is an update of the patch series at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614811.html
>
> Changes since v2:
>
> - Use a separate 'hash_set' to track expired variables instead of
> adding a flag to 'lang_decl_base'.
> - Use 'ilo
This patch optimizes cases like:
vector double v1, v2;
/* ... */
v2 = vec_splats (vec_extract (v1, 0); /* or */
v2 = vec_splats (vec_extract (v1, 1);
Previously:
vector long long
splat_dup_l_0 (vector long long v)
{
return __bu
If we are converting an unsigned DImode to a TImode value, and the TImode value
will go in a vector register, GCC currently does the DImode to TImode conversion
in GPR registers, and then moves the value to the vector register via a mtvsrdd
instruction.
This patch adds a new zero_extendditi2 insn
Also change some internal variables and function arguments from int to bool.
gcc/ChangeLog:
* reorg.cc (stop_search_p): Change return type from int to bool
and adjust function body accordingly.
(resource_conflicts_p): Ditto.
(insn_references_resource_p): Change return type from in
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 .
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE, --with-cpu=powe
I forgot to add:
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE, --with-cpu=power10, IBM 128-bit long double
* Power9, LE, --with-cpu=power9, IBM 128-bit long double
* Power9, LE, --with-cpu=po
I forgot to add:
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE, --with-cpu=power10, IBM 128-bit long double
* Power9, LE, --with-cpu=power9, IBM 128-bit long double
* Power9, LE, --with-cpu=po
Hi!
On Mon, Jul 10, 2023 at 03:59:44PM -0400, 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 .
This patch does that, you mean.
> --- a/gcc/config/rs6000/vsx.md
> +++ b/
Running
$ make check-g++
RUNTESTFLAGS='--target_board=unix\{-D_GLIBCXX_USE_CXX11_ABI=0,\}
dg.exp=allocator-opt1.C'
yields:
FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++98 scan-tree-dump-times gimple
"struct allocator D" 1
FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++14 scan-tree-dump-ti
On Mon, 10 Jul 2023, Alexander Monakov wrote:
> > I chose to make it possible to write function definitions with that
> > attribute with GCC adding the necessary callee save/restore code in
> > the xlogue itself.
>
> But you can't trivially restore if the callee is sibcalling — what
> happens the
On 7/10/23 2:18 PM, Carl Love wrote:
> + /* Get the current FPSCR fields, bits 29:31 (DRN) and bits 56:63 (VE, OE,
> UE,
> + ZE, XE, NI, RN) from the FPSCR and return them. */
The 'Z' above should line up directly under the 'G' in Get.
> - /* Insert new RN mode into FSCPR. */
> -
I noted that all memory spaces are supported, some by falling
back to the default ("malloc") - except for omp_high_bw_mem_space
(unless the memkind lib is available).
I think it makes more sense to fallback to 'malloc' also for
omp_high_bw_mem_space.
Additionally, I updated the documentation to
On Mon, Jul 10, 2023 at 03:10:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jul 10, 2023 at 03:59:44PM -0400, 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 use
On 7/10/23 11:47 AM, Peter Bergner wrote:
> While helping someone on the team debug an issue, I noticed some redundant
> tests in a couple of our predicates which can be removed. I'm going to
> commit the following as obvious once bootstrap and regtesting come back
> clean.
>
> Peter
>
>
> rs60
On 6/29/23 4:31 AM, Kewen.Lin via Gcc-patches wrote:
> This is okay for trunk (no backports needed btw), this fix can even be
> taken as obvious, thanks!
>
>>
>> 2023-06-07 Jeevitha Palanisamy
>>
>> gcc/
>> PR target/106907
>
> One curious question is that this PR106907 seemed not to repo
On Tue, Jul 11, 2023 at 12:24 AM Alexander Monakov via Gcc-patches
wrote:
>
>
> On Mon, 10 Jul 2023, liuhongt via Gcc-patches wrote:
>
> > False dependency happens when destination is only updated by
> > pternlog. There is no false dependency when destination is also used
> > in source. So either
Peter:
On Mon, 2023-07-10 at 16:57 -0500, Peter Bergner wrote:
> On 7/10/23 2:18 PM, Carl Love wrote:
> > + /* Get the current FPSCR fields, bits 29:31 (DRN) and bits 56:63
> > (VE, OE, UE,
> > + ZE, XE, NI, RN) from the FPSCR and return them. */
>
> The 'Z' above should line up directly unde
Bootstraped and Regression on X86 last night with no surprise fails.
This patch has already included 'BIAS' argument.
Ok for trunk ?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-07-10 19:35
To: gcc-patches
CC: richard.sandiford; rguenther; Ju-Zhe Zhong
Subject: [PATCH V2] VECT: Add COND
on 2023/7/10 18:40, Richard Biener wrote:
> On Fri, 7 Jul 2023, juzhe.zh...@rivai.ai wrote:
>
>> From: Ju-Zhe Zhong
>>
>> Hi, Richard and Richi.
>>
>> This patch is adding cond_len_* operations pattern for target support
>> loop control with length.
>
> It looks mostly OK - the probably obvious
Hi Carl,
on 2023/7/8 04:40, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 5. Removed -compile from the names of the compile only tests. Fixed
> up the reference to the compile file names in the .h file headers.
> Replaced powerpc_vsx_ok with vsx_hw in the run test files. Removed the
> -save-te
Hi, Kewen.
You mean COND_LEN_* family I added is unlikely used by power in the future?
Could you revise them to make it possible used by power in the future so that
we won't duplicate to many patterns.
For example, COND_LEN_* has mask operand, is it possible that power can also
use it with dummy
on 2023/7/11 07:11, Peter Bergner wrote:
> On 6/29/23 4:31 AM, Kewen.Lin via Gcc-patches wrote:
>> This is okay for trunk (no backports needed btw), this fix can even be
>> taken as obvious, thanks!
>>
>>>
>>> 2023-06-07 Jeevitha Palanisamy
>>>
>>> gcc/
>>> PR target/106907
>>
>> One curious
Hi Juzhe,
> Hi, Kewen.
>
> You mean COND_LEN_* family I added is unlikely used by power in the future?
Since AFAIK there is no plan to extend len family on Power, it's very likely
that
Power will have no chance to leverage them, so yes.
> Could you revise them to make it possible used by power
Attached is an updated version of the patch.
Based on Philipp's review, some changes:
1. Defined new enum fma_state to describe the state of FMA candidates
for a list of operands. (Since the tests seems simple after the
change, I didn't add predicates on it.)
2. Changed return type of conve
Similar like we did for cmpxchg, but extended to all
ix86_comparison_int_operator since cmpccxadd set EFLAGS exactly same
as CMP.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,},
Ok for trunk?
gcc/ChangeLog:
PR target/110591
* config/i386/sync.md (cmpccxadd_): Add a new
Please ignore this patch, I'm testing another patch to separate non
swap operands case where a setcc is not needed in the peephole2.
On Tue, Jul 11, 2023 at 11:14 AM liuhongt via Gcc-patches
wrote:
>
> Similar like we did for cmpxchg, but extended to all
> ix86_comparison_int_operator since cmpcc
Hi all,
Currently on trunk, both usage of intrin and builtin for 128 bit VAES
ISA will result in ICE since we did not check AVX512VL until pattern,
which is not user expected. This patch aims to fix that ICE and throw
an error under this scenario.
Regtested on x86-64-linux-gnu{-m32,}. Ok for trun
On Tue, Jul 11, 2023 at 11:40 AM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> Currently on trunk, both usage of intrin and builtin for 128 bit VAES
> ISA will result in ICE since we did not check AVX512VL until pattern,
> which is not user expected. This patch aims to fix that ICE and thro
Here's updated patch.
1. use optimize_insn_for_speed_p instead of using optimize_function_for_speed_p.
2. explicitly move memory to dest register to avoid false dependence in
one_cmpl pattern.
False dependency happens when destination is only updated by
pternlog. There is no false dependency whe
From: Christoph Müllner
Recently, two identical XTheadCondMov tests have been added, which both fail.
Let's fix that by changing the following:
* Merge both files into one (no need for separate tests for rv32 and rv64)
* Drop unrelated attribute check test (we already test for `th.mveqz`
and `t
on 2023/7/11 03:18, Carl Love wrote:
> On Fri, 2023-07-07 at 12:06 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> Some more minor comments are inline below on top of Peter's
>> insightful
>> review comments.
>>
>> on 2023/7/1 08:58, Carl Love wrote:
>>> GCC maintainers:
>>>
>>> Ver 2, Went back thru th
Hi Carl,
Excepting for Peter's review comments, some nits are inline below.
on 2023/7/11 03:18, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 3, Renamed the patch per comments on ver 2. Previous subject line
> was " [PATCH ver 2] rs6000, __builtin_set_fpscr_rn add retrun value".
> Fixed spel
... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
never longer (yet sometimes shorter) than the corresponding VSHUFPS /
VPSHUFD, due to the immediate operand of the shuffle insns balancing the
(uniform) need for VEX3 in the broadcast ones. When EVEX encoding is
respective the br
There's nothing AVX512BW-ish in here, so no reason to use Yw as the
constraints for the AVX alternative. Furthermore by using the 512-bit
form of VPSSLD (in a new alternative) all 32 registers can be used
directly by the insn without AVX512VL needing to be enabled.
Also adjust the originally last
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, July 11, 2023 2:04 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kirill Yukhin ; Liu, Hongtao
>
> Subject: [PATCH v3] x86: make better use of VBROADCASTSS /
> VPBROADCASTD
>
> ... in vec_dupv4sf / *vec_dupv4si. The respective broadcast
From: Ju-Zhe Zhong
This patch is to recognize specific permutation pattern which can be applied
compress approach.
Consider this following case:
#include
typedef int8_t vnx64i __attribute__ ((vector_size (64)));
#define MASK_64\
On Mon, Jul 10, 2023 at 9:08 PM Alexander Monakov via Gcc-patches
wrote:
>
>
> On Mon, 10 Jul 2023, Michael Matz via Gcc-patches wrote:
>
> > Hello,
> >
> > the ELF psABI for x86-64 doesn't have any callee-saved SSE
> > registers (there were actual reasons for that, but those don't
> > matter anym
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, July 11, 2023 2:08 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; Kirill Yukhin
>
> Subject: [PATCH] x86: improve fast bfloat->float conversion
>
> There's nothing AVX512BW-ish in here, so no reason to use Yw as the
> con
1 - 100 of 101 matches
Mail list logo
