The following committed patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
The patch was successfully bootstrapped and tested on x86-64.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d63b83194d5..4ea81e6c404 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+20
The following committed patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185
The patch was successfully bootstrapped and tested on x86-64.
On 2020-03-20 1:19 p.m., Richard Sandiford wrote:
Ping
Richard, sorry. I missed your original message.
Richard Sandiford writes:
[See:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541694.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541759.html
for a walkthrough
On 2020-03-30 12:06 p.m., David Malcolm wrote:
It's a double-free bug in lra.c, albeit one that requires being used
in a multithreaded way from libgccjit to be triggered.
libgccjit's test-threads.c repeatedly compiles and runs numerous tests,
each in a separate thread.
Attempting to add an em
The following patch improves hard reg pref cost propagation in IRA.
Hard reg preferences are created mainly from moves involving hard regs
in RTL.
The patch does the propagation during coloring now and also updates
conflict costs which affects hard reg preferences for conflicting allocnos
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
The patch was successfully bootstrapped and tested on x86-64. I did not
test it on other major targets as they do not deal with STRICT_LOW_PART.
There is also no test case for this PR as it is hard to che
On 2020-06-04 12:17 p.m., Jakub Jelinek wrote:
On Thu, Jun 04, 2020 at 12:13:51PM -0400, Vladimir Makarov via Gcc-patches
wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
The patch was successfully bootstrapped and tested on x86-64. I did not
On 2020-06-04 12:55 p.m., H.J. Lu wrote:
On Thu, Jun 4, 2020 at 9:17 AM Jakub Jelinek via Gcc-patches
wrote:
The testcase from the PR was a dg-do run testcase that FAILed without your
patch, can't we just use that testcase (in gcc.target/i386/, restricted to
lp64 and possibly linux only to m
I've added the testcase for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
diff --git a/gcc/testsuite/gcc.target/i386/pr95464.c b/gcc/testsuite/gcc.target/i386/pr95464.c
new file mode 100644
index 000..33a8290e0cf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr95464.c
@@ -0,0 +
On 2020-12-10 10:12 a.m., Andrea Corallo wrote:
Hi all,
following discussion on PR97092 I'd like to submit the following patch
with a fix plus associated testcase.
With this patch applied mode is recomputed at each iteration while
looping across different copies in 'update_costs_from_allocno'
On 2020-12-14 11:23 a.m., Andrea Corallo wrote:
Vladimir Makarov writes:
On 2020-12-10 10:12 a.m., Andrea Corallo wrote:
Hi all,
following discussion on PR97092 I'd like to submit the following patch
with a fix plus associated testcase.
With this patch applied mode is recomputed at each i
The following fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
The patch was successfully bootstrapped on x86-64.
commit fbf9b2b634e376516cd21d7aa92ef3fd5778aa10 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Wed Jan 6 14:48:53 2021 -0500
[PR97978] LRA: Permit temporary all
On 2021-01-07 6:01 a.m., Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
The following fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
The patch was successfully bootstrapped on x86-64.
Can you explain this a bit more? The assert fires if the register
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
The patch was successfully bootstrapped on x86-64.
[PR97969] LRA: Transform pattern `plus (plus (hard reg, const), pseudo)` after elimination
LRA can loop infinitely on targets without `reg + imm` insns. Register e
On 2021-01-18 7:50 a.m., Richard Biener wrote:
On Mon, 18 Jan 2021, Przemyslaw Wirkus wrote:
Hi all,
Can we backport PR97969 patch to GCC 10 and (maybe) GCC 9 ?:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
IMHO bug is severe and could land in GCC 10 and 9. Vladimir's original patch:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
[PR97847] IRA: Skip abnormal critical edge splitting
PPC64 can generate jumps with clobbered pseudo-regs and a BB with
such jump can have abno
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
The patch was successfully bootstrapped and tested on x86-64.
[PR98722] LRA: Check that target has no 3-op add insn to transform 2 plus expression.
Patch cf2ac1c30af0fa783c8d72e527904dda5d8cc330 for solving PR97969
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97870
The patch was successfully bootstrapped and tested on x86-64.
[PR97870] LRA: don't remove asm goto, just nullify it.
gcc/
2020-11-18 Vladimir Makarov
PR target/97870
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
The patch was successfully bootstrapped on x86-64 and s390x.
commit fb352136db34a7adbc7be6a1e4e90b56bc632ebd (HEAD -> master)
Author: Vladimir N. Makarov
Date: Tue Nov 24 11:25:16 2020 -0500
[PR97933] LRA: f
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983
The patch was successfully bootstrapped on x86_64 and s390x (with
--enable-languages=c,c++ --enable-checking=release --disable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable
On 2020-10-14 10:21 a.m., Martin Liška wrote:
Hello.
There's a new version of the patch that fixes profile scaling
in IRA.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Yes. Thank you, Martin.
On 2020-10-11 8:58 p.m., Hongtao Liu wrote:
Hi:
This is done in 2 steps:
1. Extend special memory constraint to handle non MEM_P cases, i.e.
(vec_duplicate:V4SF (mem:SF (addr)))
2. Refactor implementation of *_bcst{_1,_2,_3} patterns. Add new
predicate bcst_mem_operand and correspondin
On 2020-10-20 1:33 a.m., Hongtao Liu wrote:
On Mon, Oct 19, 2020 at 11:38 PM Vladimir Makarov wrote:
On 2020-10-11 8:58 p.m., Hongtao Liu wrote:
Hi:
This is done in 2 steps:
1. Extend special memory constraint to handle non MEM_P cases, i.e.
(vec_duplicate:V4SF (mem:SF (addr)))
On 2020-10-20 10:11 p.m., Hongtao Liu wrote:
Changed, and it passed the i386/x86-64 regression test.
Update patch.
Thank you, Hongtao. This patch is ok for the trunk.
The following patch implements taking insn scratch requirements into
account in global RA (IRA). Before the patch IRA simply ignored insn
scratches. Only LRA took the scratches into account and assigned hard
registers to scratches if neccessary. In some cases it resulted in
spilling pseudos wh
The following patch fixes failures for test p9-extract-2.c on
ppc64. The failures are a result of committing patch dealing with insn
scratches in IRA. The pseudo corresponding the 1st scratch in the
following insn get unexpected register class (general regs) and
unexpected insn alternative (th
On 2022-11-07 04:46, Max Filippov wrote:
gcc/
* ira-color.cc (update_costs_from_allocno): Check that allocno
is in the consideration_allocno_bitmap before dereferencing
ALLOCNO_COLOR_DATA (allocno).
---
This fixes the invalid memory access, but I'm not sure if that's
suf
The following patch fixes test failure of 20030222-1.c on moxie port.
But the problem can occur on other targets. The patch actually
implements the old reload approach for the test case.
The patch was successfully tested and bootstrapped on x86-64, aarch64,
and ppc64le.
commit 51703ac3c722
On 4/19/23 20:46, liuhongt via Gcc-patches wrote:
1547 /* If this insn loads a parameter from its stack slot, then it
1548 represents a savings, rather than a cost, if the parameter is
1549 stored in memory. Record this fact.
1550
1551 Similarly if we're loading other constants fr
On 5/5/23 12:59, Richard Sandiford wrote:
This patch follows on from g:9f635bd13fe9e85872e441b6f3618947f989909a
("the previous patch"). To start by quoting that:
If an insn requires two operands to be tied, and the input operand dies
in the insn, IRA acts as though there were a copy from the
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit 265a749f290f7c6adc9a3aaa9c585b498a8a38ea
Author: Vladimir N. Makarov
Date: Tue Jan 24 16:10:59 2023 -0500
LRA: Alwa
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit f661c0bb6371f355966a67b5ce71398e80792948
Author: Vladimir N. Makarov
Date: Tue Feb 7 08:27:36 2023 -0500
RA: Implemen
On 2/7/23 22:48, Andrew Pinski wrote:
On Tue, Feb 7, 2023 at 6:08 AM Vladimir Makarov via Gcc-patches
wrote:
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
What languages
This is another try to solve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
The patch was successfully bootstrapped (--enable-languages=all) and
tested on x86, x86-64, aarch64
commit 1ad898d18904ac68432ba9b8ffa2b083d007cc2d
Author: Vladimir N. Makarov
Date: Thu Feb 9 15:18:48 2023 -0500
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
The patch improves compilation speed. Compilation time of the biggest
test in the PR decreases from 1235s to 709s.
The patch was successfully bootstrapped on x86-64.
commit 02371cdd755d2b53fb580d3e8209c44e0c45c337
The following patch should solve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754
The patch simply switches off a new optimization for targets using the
old reload pass.
The patch was successfully bootstrapped on x86-64.
commit 7757567358a84c3774cb972350bd7ea299daaa8d
Author: Vladimir
On 2022-05-24 23:39, liuhongt wrote:
Rigt now, mem_cost for separate mem alternative is 1 * frequency which
is pretty small and caused the unnecessary SSE spill in the PR, I've tried
to rework backend cost model, but RA still not happy with that(regress
somewhere else). I think the root cause o
On 2022-05-29 23:05, Hongtao Liu wrote:
On Fri, May 27, 2022 at 5:12 AM Vladimir Makarov via Gcc-patches
wrote:
On 2022-05-24 23:39, liuhongt wrote:
Rigt now, mem_cost for separate mem alternative is 1 * frequency which
is pretty small and caused the unnecessary SSE spill in the PR, I&#x
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and arm64. Unfortunately, I did not manage to reduce the test (whose
size is 5MB).
commit 9725df0233b6fb6e761875968b3b8e9fd9f522ac (HEAD -> m
On 2021-03-09 9:26 a.m., Jakub Jelinek wrote:
On Tue, Mar 09, 2021 at 09:12:36AM -0500, Vladimir Makarov via Gcc-patches
wrote:
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 76e3ff7efe6..feff766c590 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -3452,6
On 2021-03-09 9:53 a.m., Martin Liška wrote:
On 3/9/21 3:12 PM, Vladimir Makarov via Gcc-patches wrote:
The patch was successfully bootstrapped and tested on x86-64,
ppc64le, and arm64. Unfortunately, I did not manage to reduce the
test (whose size is 5MB).
I've just reduced test
Here is the patch taking all the proposals into account.
Successfully bootstrapped on x86-64.
commit 7ad6b73421e3599628bf52fb175f004ce13f2ae9 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Tue Mar 9 10:57:21 2021 -0500
[PR99454] LRA: Process separately 'g' and digital constraints >
While working on PR99454 I found that IR incorrectly processes
constraints starting with '0'..'9' and containing more one digit. It is
probably a rare event and it does not result in wrong code generation.
Simply, the generated code will be more efficient.
In any case the following patch fixe
On 2021-03-10 5:25 a.m., Andre Vieira (lists) wrote:
On 19/02/2021 15:05, Vladimir Makarov wrote:
On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
Hi,
This patch makes sure that allocno copies are not created for
unordered modes. The testcases in the PR highlighted a case where an
al
Here is one more patch for PR99422. The patch was successfully tested
and bootstrapped on x86-64.
commit e647130d441887657cf0e1c2c3b40ab1ca9beb47 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Wed Mar 10 16:15:08 2021 -0500
[PR99422] LRA: Don't check unknown constraint, use X for e
This is an additional patch for PR99422:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and aarch64.
commit a4670f58ebff805e35268542aac35f9791980954
Author: Vladimir N. Makarov
Date: Thu Mar 18 15:58:26 2021 -0400
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch was successfully tested and bootstrapped on x86-64, ppc64le,
aarch64.
Is it ok for the trunk?
commit 20a38c39e57fe4d8a72391184e3b67129f0bf88c
Author: Vladimir N. Makarov
Date: Fri Mar 1
On 2021-03-19 11:03 a.m., Alex Coplan wrote:
Hi Vladimir,
On 19/03/2021 10:21, Vladimir Makarov via Gcc-patches wrote:
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch was successfully tested and bootstrapped on x86-64, ppc64le
On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch was successfully tested and bootstrapped on x86-64, ppc64le,
aarch64.
Is it ok for the trunk
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99663
The patch was successfully bootstrapped and tested on x86-64.
commit d81019db099ad95febbb2d4b4afd8cbe95762062
Author: Vladimir N. Makarov
Date: Fri Mar 19 15:34:48 2021 -0400
[PR99663] Don't use unknown constr
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680
The patch was successfully bootstrapped on x86-64.
commit c1ab0c0336d85f5e97739060ecf77fd05ac86d2a
Author: Vladimir N. Makarov
Date: Sat Mar 20 10:50:03 2021 -0400
[PR99680] Check empty constraint before using
On 2021-03-22 6:22 a.m., Richard Sandiford wrote:
'\0' is just a normal string null terminator and so I don't think we
should be processing it as if it were a constraint character.
How about having a gcc_unreachable on zero instead?
I would be nice to use gcc_unreachable but it requires to re
On 2021-03-21 8:51 a.m., Richard Sandiford wrote:
Vladimir Makarov writes:
On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch was
On 2021-03-23 9:07 a.m., Christophe Lyon wrote:
On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
wrote:
Hi,
This patch causes regressions (116) on aarch64:
gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c -std=gnu90 -O2
On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov wrote:
Can you check?
Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
and I don't see the regressions mentioned above.
Can you check this too and if I am doing something wr
On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov
wrote:
Can you check?
Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
and I don't see the regressions mentioned above.
Can
On 2021-03-23 5:33 p.m., Richard Sandiford wrote:
Vladimir Makarov writes:
On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
Here is the patch solving the problem.
Also although asm tests only checks assembler code, a lot of them use
dg-require-effective-target and therefore can not be tes
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
The patch was successfully bootstrapped and tested on aarch64.
commit 0d37e2d3ead072ba57e03fcb97a041504a22e721
Author: Vladimir Makarov
Date: Fri Mar 26 17:09:24 2021 +
[PR99766] Consider relaxed memory
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and aarch64.
commit 1458059fc1faf6170f2fe45159065f91876307ac
Author: Vladimir N. Makarov
Date: Wed Mar 31 13:26:30 2021 -0400
[PR99781
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100066
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
commit f99f64f69db49ce6343d79a39eab28dcc6b91865
Author: Vladimir N. Makarov
Date: Wed Apr 14 13:21:40 2021 -0400
[PR100066]
On 2021-04-23 12:13 p.m., Richard Sandiford wrote:
This is a backport of the PR96796 fix to GCC 10 and GCC 9. The original
trunk patch was:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552878.html
reviewed here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/55330
On 2021-06-28 2:26 a.m., Kewen.Lin wrote:
Hi!
on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
Hi,
PR100328 has some details about this issue, I am trying to
brief it here. In the hottest function LBM_performStreamCollideTRT
of SPEC2017 bmk 519.lbm_r, there are many FMA style expression
On 2021-06-28 2:26 a.m., Kewen.Lin wrote:
Hi!
on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
Hi,
PR100328 has some details about this issue, I am trying to
brief it here. In the hottest function LBM_performStreamCollideTRT
of SPEC2017 bmk 519.lbm_r, there are many FMA style expression
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106462
The patch was successfully bootstrapped and tested on x86-64.
commit 70596a0fb2a2ec072e1e97e37616e05041dfa4e5
Author: Vladimir N. Makarov
Date: Fri Dec 2 08:18:04 2022 -0500
LRA: Check hard reg availability
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
After some observation, if all is ok, I will commit the patch into gcc
release branches mentioned in the PR.
[PR99531] Modify
This is one more patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
The following patch fixes the test failure on ia32.
commit 4ddeae2b2777aa5136fc2bb21c15b0fcccdafece
Author: Vladimir N. Makarov
Date: Tue Dec 14 08:57:30 2021 -0500
[PR99531] Do not scan push insn for ia32 in
On 2022-01-06 09:45, Richard Sandiford wrote:
This series of patches recovers the exchange2 performance lost in the
GCC 11 timeframe (at least on aarch64 and Power9 -- thanks Pat for
testing the latter).
There are 6 patches, split into two groups of 3. The first 3 are just
preparatory patches
On 2022-01-06 09:46, Richard Sandiford wrote:
The final index into (ira_)memory_move_cost is 1 for loads and
0 for stores. Thus the combination:
entry_freq * memory_cost[1] + exit_freq * memory_cost[0]
is the cost of loading a register on entry to a loop and
storing it back on exit from t
On 2022-01-06 09:46, Richard Sandiford wrote:
This patch adds comments to describe each use of ira_loop_border_costs.
I think this highlights that move_spill_restore was using the wrong cost
in one case, which came from tranposing [0] and [1] in the original
(pre-ira_loop_border_costs) ira_memo
On 2022-01-06 09:47, Richard Sandiford wrote:
color_pass has two instances of the same code for propagating non-cap
assignments from parent loops to subloops. This patch adds a helper
function for testing when such propagations are required for correctness
and uses it to remove the duplicated
On 2022-01-06 09:47, Richard Sandiford wrote:
Suppose that:
- an inner loop L contains an allocno A
- L clobbers hard register R while A is live
- A's parent allocno is AP
Previously, propagate_allocno_info would propagate conflict sets up the
loop tree, so that the conflict between A and R w
On 2022-01-06 09:48, Richard Sandiford wrote:
If an allocno A in an inner loop L spans a call, a parent allocno AP
can choose to handle a call-clobbered/caller-saved hard register R
in one of two ways:
(1) save R before each call in L and restore R after each call
(2) spill R to memory through
On 2022-01-06 09:48, Richard Sandiford wrote:
This patch looks for allocno conflicts of the following form:
- One allocno (X) is a cap allocno for some non-cap allocno X2.
- X2 belongs to some loop L2.
- The other allocno (Y) is a non-cap allocno.
- Y is an ancestor of some allocno Y2 in L2.
-
On 2022-01-11 12:42, Richard Sandiford wrote:
The new IRA heuristics would need more work on old-reload targets,
since flattening needs to be able to undo the cost propagation.
It's doable, but hardly seems worth it.
Agree. It is not worth to spend your time for work for reload.
This patch th
On 2022-01-12 03:47, Richard Biener wrote:
On Tue, Jan 11, 2022 at 7:41 PM Vladimir Makarov via Gcc-patches
wrote:
On 2022-01-11 12:42, Richard Sandiford wrote:
The new IRA heuristics would need more work on old-reload targets,
since flattening needs to be able to undo the cost propagation
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
The patch was successfully bootstrapped and tested on x86-64, i686,
aarch64, and ppc64le.
commit 57688950b9328cbb4a9c21eb3199f9132b5119d3
Author: Vladimir N. Makarov
Date: Fri Mar 17 08:58:58 2023 -0400
LRA:
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
The patch was successfully bootstrapped and tested on x86-64.
commit 81d762cbec9685c2f2571da21d48f42c42eff33b
Author: Vladimir N. Makarov
Date: Wed Mar 22 12:33:11 2023 -0400
LRA: Do not repeat inheritance an
This is one more patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
The patch adds trying commutative operands exchange for recently
implemented combining secondary memory reload and original insn:
The patch was successfully bootstrapped and tested on x86_64.
commit 378d19cfebfa2b
On 4/4/23 21:29, Jeff Law wrote:
On 4/3/23 23:13, liuhongt via Gcc-patches wrote:
There's a potential performance issue when backend returns some
unreasonable value for the mode which can be never be allocate with
reg class.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for t
101 - 179 of 179 matches
Mail list logo
