Update my email address.
ChangeLog:
* MAINTAINERS: Update claziss email address.
Signed-off-by: Claudiu Zissulescu
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 41319595bb5..ddeea7b497f 100644
--- a/MAINTAINERS
+++
The following adds support for single-lane SLP .GOMP_SIMD_LANE
vectorization.
This doesn't handle much, esp. g++.dg/vect/simd-*.cc with their
'inscan' uses are unhandled.
* tree-vect-slp.cc (no_arg_map): New.
(vect_get_operand_map): Handle IFN_GOMP_SIMD_LANE.
(vect_build_s
The following fixes an ICE with a .COND_ADD discovered as reduction
even though its else value isn't the reduction chain link but a
constant. This would be wrong-code with --disable-checking I think.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/115723
Add some missing APX NF and NDD support for imul and mul.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386.md (*imulhizu): Added APX
NF support.
(*imulhizu): New define_insn.
(*mulsi3_1_zext): Ditto.
The libffi.closures/single_entry_structs2.c test FAILs on 32-bit SPARC:
FAIL: libffi.closures/single_entry_structs2.c -W -Wall -Wno-psabi -O0 execution
test
The issue has been reported, analyzed and fixed upstream:
Several tests FAIL on 32-bit Solaris/SPARC
https://github.com/li
> The issue has been reported, analyzed and fixed upstream:
>
> Several tests FAIL on 32-bit Solaris/SPARC
> https://github.com/libffi/libffi/issues/841
>
> Therefore this patch imports the fix into the GCC tree.
>
> Tested on sparc-sun-solaris2.11. Ok for trunk?
Sure, thanks!
--
From: Pan Li
This patch would like to implement the simple .SAT_TRUNC pattern
in the riscv backend. Aka:
Form 1:
#define DEF_SAT_U_TRUC_FMT_1(NT, WT) \
NT __attribute__((noinline)) \
sat_u_truc_##WT##_to_##NT##_fmt_1 (WT x) \
{\
In preparation of dropping vcond{,u,eq} optabs
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654690.html
enable 128-bit operands for vcond_mask---including integer as well as
floating point.
This fixes partially PR115519 w.r.t. autovec-long-double-signaling-*.c
tests.
gcc/ChangeLog:
gcc/ChangeLog:
* doc/invoke.texi: Document -fasm.
Signed-off-by: Alejandro Colomar
---
gcc/doc/invoke.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 30c4b002d1f..2d55f2715b3 100644
--- a/gcc/doc/invoke.texi
From: Deepthi Hemraj
For excessively long environment variables i.e >128KB
Store the arguments in a temporary file and collect them back together in
collect2.
This commit patches for COLLECT_GCC_OPTIONS issue:
GCC should not limit the length of command line passed to collect2
https://gcc.gnu.or
On Thu, 13 Jun 2024, Alexandre Oliva wrote:
> Before issuing loads or stores for a block move, adjust the MEM
> alignments if analysis of the addresses enabled the inference of
> stricter alignment. This ensures that the MEMs are sufficiently
> aligned for the corresponding insns, which avoids tr
On Mon, Jul 01, 2024 at 11:37:40AM +0200, Alejandro Colomar wrote:
> gcc/ChangeLog:
>
> * doc/invoke.texi: Document -fasm.
Why? We have almost 1300 options which accept the negative forms
and we don't document any of them this way, the manual explicitly states
that:
Many options have long
On Tue, 18 Jun 2024, Maciej W. Rozycki wrote:
> Fix the problem by moving the renaming of gnattools to a separate 'make'
> recipe, pasted into a new 'gnattools-cross-mv' target and the existing
> legacy 'cross-gnattools' target. Then invoke the new target explicitly
> from the 'gnattools-cross
On Mon, Jul 01, 2024 at 12:40:45PM GMT, Jakub Jelinek wrote:
> On Mon, Jul 01, 2024 at 11:37:40AM +0200, Alejandro Colomar wrote:
> > gcc/ChangeLog:
> >
> > * doc/invoke.texi: Document -fasm.
>
> Why? We have almost 1300 options which accept the negative forms
> and we don't document any of
Applied some fixes / skips to test cases.
Johann
PR testsuite/52641
gcc/testsuite/
* gcc.dg/analyzer/pr109577.c: Use __SIZE_TYPE__ instead of
"unsigned long".
* gcc.dg/analyzer/pr93032-mztools-signed-char.c: Requires
int32plus.
* gcc.dg/analyzer/pr93032-mztools-
Applies this patch to fix code when the destination
register overlaps with a hard register used by insn
xload_A resp. xload8qi_A (PR115726).
Also fixed PR88236 in one go because that PR is very
similar in its outcome, and it's not possible to discriminate
in a test case which is which, resp. when
Hi Richard!
On 2024-06-28T17:48:30+0100, Richard Sandiford
wrote:
> Richard Sandiford writes:
>> Thomas Schwinge writes:
>>> On 2024-06-27T23:20:18+0200, I wrote:
On 2024-06-27T22:27:21+0200, I wrote:
> On 2024-06-27T18:49:17+0200, I wrote:
>> On 2023-10-24T19:49:10+0100, Richard
Hi!
On 2024-06-28T00:41:54+0200, I wrote:
> On 2024-06-27T23:20:18+0200, I wrote:
>> On 2024-06-27T22:27:21+0200, I wrote:
>>> On 2024-06-27T18:49:17+0200, I wrote:
On 2023-10-24T19:49:10+0100, Richard Sandiford
wrote:
> This patch adds a combine pass that runs late in the pipeline
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-07-01 09:35
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 3/4] RISC-V: Add testcases for unsigned scalar .SAT_ADD IMM
form 3
From: Pan Li
This patch would like to add test cases for the unsi
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-07-01 09:35
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 2/4] RISC-V: Add testcases for unsigned scalar .SAT_ADD IMM
form 2
From: Pan Li
This patch would like to add test cases for the unsi
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-07-01 09:35
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 4/4] RISC-V: Add testcases for unsigned scalar .SAT_ADD IMM
form 4
From: Pan Li
This patch would like to add test cases for the unsi
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-07-01 09:35
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 1/4] RISC-V: Add testcases for unsigned scalar .SAT_ADD IMM
form 1
From: Pan Li
This patch would like to add test cases for the unsi
Thomas pointed out that we sometimes failed to eliminate some dead code
(specifically clobbers of otherwise unused registers) on nvptx when
late-combine is enabled. This happens because:
- combine is able to optimise the function in a way that exposes dead code.
This leaves the df information i
Mode iterator V_HW enables V1TI for target VXE which means
vec_cmpv1tiv1ti becomes available which leads to an ICE since there is
no corresponding insn.
Fixed by emulating comparisons and enabling mode V1TI unconditionally
for V_HW. For the sake of symmetry, I also added TI mode to V_HW since
TF
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
Thanks
Gui Haochen
在 2024/6/24 9:40, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
>
> Thanks
> Gui Haochen
>
> 在 2024/6/20 14:56, HAO CHEN GUI 写道:
This patch adds an additional variation of the peephole2 used to convert
bswaphisi2_lowpart into rotlhi3_1_slp, which converts xchgb %ah,%al into
rotw if the flags register isn't live. The motivating example is:
void ext(int x);
void foo(int x)
{
ext((x&~0x)|((x>>8)&0xff)|((x&0xff)<<8));
}
The problem should be fixed after my value range patches being accepted.
[PATCH-1v3] Value Range: Add range op for builtin isinf
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
[PATCH-2v4] Value Range: Add range op for builtin isfinite
https://gcc.gnu.org/pipermail/gcc-patches/2024-M
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653095.html
Thanks
Gui Haochen
在 2024/6/24 9:41, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653095.html
>
> Thanks
> Gui Haochen
>
> 在 2024/6/20 14:58, HAO CHEN GUI 写道:
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html
Thanks
Gui Haochen
在 2024/6/24 9:41, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html
>
> Thanks
> Gui Haochen
>
> 在 2024/6/20 14:57, HAO CHEN GUI 写道:
On 6/30/24 6:46 PM, Vineet Gupta wrote:
On 6/30/24 06:59, Jeff Law wrote:
Any ideas on how I can keep this and then adjust rest of patterns.
Yea. Drop the "SImode" references from the RTL template of the
expander. Then you'll need to verify the modes in the C fragment that
generates cod
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653180.html
Thanks
Gui Haochen
在 2024/6/20 15:01, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653180.html
>
> Thanks
> Gui Haochen
>
> 在 2024/5/31 11:25, HAO CHEN GUI 写道:
Optabs vcond{,u} will be removed for GCC 15. Since regtest shows no
fallout, dropping the expanders, now.
gcc/ChangeLog:
PR target/114189
* config/s390/vector.md (V_HW2): Remove.
(vcond): Remove.
(vcondu): Remove.
---
Bootstrapped and regtested on s390. Ok for m
This drops vcond expanders. The first patch
"s390: Emulate vec_cmp{eq,gt,gtu} for 128-bit integers" is somewhat
independent of the other two, since we run already in ICEs. However,
since after removing vcond expanders testsuite shows one additional
fallout without this patch, which is why I would
Hi,
Sometimes, a complicated constant is built via 3(or more)
instructions. Generally speaking, it would not be as fast
as loading it from the constant pool (as the discussions in
PR63281):
"ld" is one instruction. If consider "address/toc" adjust,
we may count it as 2 instructions. And "pld" ma
Hi,
As PR115659 shows, assuming c = x CMP y, there are some
folding chances for patterns r = c ? 0/z : z/-1:
- For r = c ? 0 : z, it can be folded into r = ~c & z.
- For r = c ? z : -1, it can be folded into r = ~c | z.
But BIT_AND/BIT_IOR applied on one BIT_NOT operand is a
compound operatio
Hi,
As PR115659 shows, assuming c = x CMP y, there are some
folding chances for patterns r = c ? -1/z : z/0.
For r = c ? -1 : z, it can be folded into:
- r = c | z (with ior_optab supported)
- or r = c ? c : z
while for r = c ? z : 0, it can be foled into:
- r = c & z (with and_optab supp
On Mon, Jul 1, 2024 at 8:16 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR115659 shows, assuming c = x CMP y, there are some
> folding chances for patterns r = c ? -1/z : z/0.
>
> For r = c ? -1 : z, it can be folded into:
> - r = c | z (with ior_optab supported)
> - or r = c ? c : z
>
> while for r =
On Mon, Jul 1, 2024 at 8:17 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR115659 shows, assuming c = x CMP y, there are some
> folding chances for patterns r = c ? 0/z : z/-1:
> - For r = c ? 0 : z, it can be folded into r = ~c & z.
> - For r = c ? z : -1, it can be folded into r = ~c | z.
>
> But BIT_
Hi,
For "-m32 -mpowerpc64", it is also ok to use fewer instruciton (p?ld)
to loading 64bit constant from memory. So, splitting the complicate 64bit
constant to constant pool should also work for this case.
Compare with previous version:
This version is using the new parameter to control what kind
*|MC:SUBJECT|* p{ margin:10px 0; padding:0; } table{
border-collapse:collapse; } h1,h2,h3,h4,h5,h6{ display:block; margin:0;
padding:0; } img,a img{ border:0; height:auto; outline:none;
text-decoration:none; } body,#bodyTable,#bodyCell{ height:100%; margin:0;
padding:0; width:100%; } .mcnPre
Andi Kleen writes:
I wanted to ping this patch kit to add musttail support for C/C++,
to enable future python versions and other users and keep up with clang.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/thread.html#655447
It unfortunately touches various different parts of the compiler
Hello Martin,
Martin Uecker writes:
> This should fix the test failures introduced by the fix for PR115157.
>
> Tested on x86_64 and also tested with -m32.
>
>
> Fix test errors introduced with fix for PR115157.
>
> Fix tests introduced when fixing PR115157 that assume
> sizeof(enu
Ping plus some extra people on Cc since I wasn't sure who to ask for review.
(Adding maintainers for `middle-end` plus Richard S).
N.b. I'd update the cover-letter to also mention that no existing
implementation of `function_attribute_inlinable_p` uses "the current
function" in any way.
On 4
On 6/28/24 7:00 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
This DR (https://cplusplus.github.io/CWG/issues/2627.html) says that
even if we are converting from an integer type or unscoped enumeration type
to an integer type that cannot re
On 6/26/24 3:00 PM, Simon Martin wrote:
The case in the ticket is an ICE on invalid due to an assert in stabilize_expr,
but the underlying issue can actually trigger on this *valid* code:
=== cut here ===
struct TheClass {
TheClass() {}
TheClass(volatile TheClass& t) {}
TheClass operato
On 6/26/24 6:04 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This is a low-prio crash on invalid code where we ICE on a VAR_DECL
with erroneous type. I thought I'd try to avoid putting such decls
into ->names and ->names_in_scope but that sounds
On 6/30/24 5:09 PM, Lewis Hyatt wrote:
Hello-
I noticed this while trying to test another patch on Windows (using the
MSYS2 environment). Tested that it fixes the issue for x86_64-w64-mingw32
and doesn't affect anything for x86_64-pc-linux-gnu. It looks like the same
fix for C was applied back i
On Mon, Jul 1, 2024 at 3:20 PM Roger Sayle wrote:
>
>
> This patch adds an additional variation of the peephole2 used to convert
> bswaphisi2_lowpart into rotlhi3_1_slp, which converts xchgb %ah,%al into
> rotw if the flags register isn't live. The motivating example is:
>
> void ext(int x);
> vo
On 6/26/24 11:42 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
This works:
template
int Func(T);
typedef int (*funcptrtype)(int);
funcptrtype fp0 = &Func;
but this doesn't:
funcptrtype fp2 = (0, &Func);
because we only ca
On 7/1/24 11:39, Matthew Malcomson wrote:
Ping plus some extra people on Cc since I wasn't sure who to ask for
review.
(Adding maintainers for `middle-end` plus Richard S).
gcc/ChangeLog:
* doc/tm.texi (function_attribute_inlinable_p,
unspec_may_trap_p): Update documentation.
* t
Hi All,
wide_int_constant_multiple_p tries to check if for two tree expressions a and b
that there is a multiplier which makes a == b * c.
This code however seems to think that there's no c where a=0 and b=0 are equal
which is of course wrong.
This fixes it and also fixes the comment.
Bootstrap
Hi All,
The current implementation of constant_multiple_of is doing a more limited
version of aff_combination_constant_multiple_p.
The only non-debug usage of constant_multiple_of will proceed with the values
as affine trees. There is scope for further optimization here, namely I believe
that if
On Mon, Jul 01, 2024 at 04:36:44PM +0200, Richard Biener wrote:
> On Mon, Jul 1, 2024 at 8:17 AM Kewen.Lin wrote:
> > As PR115659 shows, assuming c = x CMP y, there are some
> > folding chances for patterns r = c ? 0/z : z/-1:
> > - For r = c ? 0 : z, it can be folded into r = ~c & z.
> > - Fo
> -Original Message-
> From: Tamar Christina
> Sent: Monday, July 1, 2024 9:14 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> Subject: [PATCH 1/2]middle-end: fix wide_int_constant_multiple_p when VAL and
> DIV are 0. [PR114932]
>
> Hi All,
>
> wide
Hi!
On Mon, Jul 01, 2024 at 02:17:33PM +0800, Kewen.Lin wrote:
> * config/rs6000/rs6000-builtins.def: Update some bif expanders by
> replacing orc3 with iorc3.
> * config/rs6000/rs6000-string.cc (expand_cmp_vec_sequence): Update gen
> function by replacing orc3 with iorc3.
On Mon, Jul 01, 2024 at 02:44:56PM -0400, Jason Merrill wrote:
> On 6/26/24 6:04 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This is a low-prio crash on invalid code where we ICE on a VAR_DECL
> > with erroneous type. I thought I'
Hi All,
This is one of those PRs where one thing led to another I think that
the patch is pretty complete and, while apparently quite heavy, is more or
less self explanatory through comments and the ChangeLog.
The first testcase concentrates on reshape in various guises, while the
second deal
This is just a small optimization for the case where the real and imag
parts are the same when lowering complex addition/subtraction. We only
need to do the addition once when the real and imag parts are the same (on
both sides of the operator). This gets done later on by FRE/PRE/DOM but
having it
This patch series includes some improvements to complex lowering,
all related to cabs.
History of the cabs folding
cabs folding was originally add in builtins.c ( and 4.3
[r0-78875-gd1ad84c20452e6])
The expansion to `sqrt(r*r+i*i)` added to cse sincos pass in GCC 4.7
(r0-109444-gd7e2a1c13835e7) to
Expanding cabs in powcab might be too late as forwprop might
recombine the load from a memory with the complex expr. Moving
instead to complex lowering allows us to use directly the real/imag
component from the loads instead. This allows for vectorization too.
Bootstrapped and tested on x86_64-lin
While looking into the original folding code for cabs
(moved to match in r6-4111-gabcc43f5323869), I noticed that
`cabs(x+0i)` was optimized even without the need of sqrt.
I also noticed that now the code generation in this case
will be worse if the target had a sqrt. So let's implement
this small
Since cabs expansion was removed from this pass,
it would be good to rename it.
Bootstrapped and tested on x86_64-linux-gnu
gcc/ChangeLog:
* passes.def (expand_pow): Renamed from expand_powcabs.
* timevar.def (TV_TREE_POWCABS): Remove.
(TV_TREE_POW): Add
* tree-pa
On Linux/x86_64,
52d71b6b1f0f465a6cf064f61b22fc99453ec132 is the first bad commit
commit 52d71b6b1f0f465a6cf064f61b22fc99453ec132
Author: Marek Polacek
Date: Fri Jun 28 17:51:19 2024 -0400
c++: DR2627, Bit-fields and narrowing conversions [PR94058]
caused
FAIL: g++.dg/cpp2a/spaceship-nar
On 7/1/24 5:09 PM, Marek Polacek wrote:
On Mon, Jul 01, 2024 at 02:44:56PM -0400, Jason Merrill wrote:
On 6/26/24 6:04 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This is a low-prio crash on invalid code where we ICE on a VAR_DECL
with erroneo
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
I made sure that Wnarrowing22.C works fine on ILP32, but apparently
I didn't verify that spaceship-narrowing1.C works there as well. :(
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/spaceship-narrowing1.C: Use __INT64_TYPE__.
---
gcc/te
From: Pan Li
The .SAT_TRUNC has the input and output types, aka cvt from
itype to otype and the sizeof (otype) < sizeof (itype). The
previous patch only allows the sizeof (otype) == sizeof (itype) / 2.
But actually we have 1/4 and 1/8 truncation.
This patch would like to support more types tru
On Mon, Jul 1, 2024 at 4:51 PM kong lingling wrote:
>
> Add some missing APX NF and NDD support for imul and mul.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
>
> Ok for trunk?
Ok.
>
>
> gcc/ChangeLog:
>
> * config/i386/i386.md (*imulhizu): Added APX
> NF support.
From: "H.J. Lu"
According to Intel® 64 and IA-32 Architectures Optimization Reference
Manual[1], Branch Hint is updated for Redwood Cove.
cut from [1]-
Starting with the Redwood Cove microarchitecture, if the predictor has
no stored information about a branch, the
After r15-1579, ADD and LD/ST pairs will be merged into LDX/STX.
Cause these two tests to fail. To guarantee that these two tests pass,
add the compilation option '-fno-late-combine-instructions'.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/explicit-relocs-extreme-tls-desc.c:
The following two FAIL items have been fixed:
FAIL: gcc.target/loongarch/movcf2gr-via-fr.c scan-assembler
movcf2fr\\t\$f[0-9]+,\$fcc
FAIL: gcc.target/loongarch/movcf2gr-via-fr.c scan-assembler
movfr2gr.s\\t\$r4
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_i
Hi,
According to APX spec, the pushp/popp pairs should be matched,
otherwise the PPX hint cannot take effect and cause performance loss.
In the ix86_expand_epilogue, there are several optimizations that may
cause the epilogue using mov to restore the regs. Check if PPX applied
and prevent usage o
Hi,
Commit r15-1594 removed define of LONG_DOUBLE_TYPE_SIZE in
sparc.cc, it's based on the assumption that each OS has its
own define (see the comments in sparc.h), but it exposes an
issue on vxworks which lacks of the define.
We can bring back the default SPARC_LONG_DOUBLE_TYPE_SIZE to
sparc.cc,
On Tue, 2024-07-02 at 11:22 +0800, Lulu Cheng wrote:
> +static int
> +loongarch_insn_cost (rtx_insn *insn, bool speed)
> +{
> + rtx x = PATTERN (insn);
> + int cost = pattern_cost (x, speed);
> +
> + /* On LA464, prevent movcf2fr and movfr2gr from merging into movcf2gr. */
> + if (TARGET_uARCH
在 2024/7/2 上午11:50, Xi Ruoyao 写道:
On Tue, 2024-07-02 at 11:22 +0800, Lulu Cheng wrote:
+static int
+loongarch_insn_cost (rtx_insn *insn, bool speed)
+{
+ rtx x = PATTERN (insn);
+ int cost = pattern_cost (x, speed);
+
+ /* On LA464, prevent movcf2fr and movfr2gr from merging into movcf2gr.
From: Pan Li
Update in v2:
Rebase the upstream.
Log in v1:
This patch would like to implement the simple .SAT_TRUNC pattern
in the riscv backend. Aka:
Form 1:
#define DEF_SAT_U_TRUC_FMT_1(NT, WT) \
NT __attribute__((noinline)) \
sat_u_truc_##WT##_to_##NT##_fmt_1 (WT x) \
75 matches
Mail list logo
