https://gcc.gnu.org/g:44e7855e4e817a7f5a1e332cd95e780e57052dba
commit r15-436-g44e7855e4e817a7f5a1e332cd95e780e57052dba
Author: Vladimir N. Makarov
Date: Mon May 13 10:12:11 2024 -0400
[PR115013][LRA]: Modify register starvation recognition
My recent patch to recognize reg
https://gcc.gnu.org/g:9585317f0715699197b1313bbf939c6ea3c1ace6
commit r15-364-g9585317f0715699197b1313bbf939c6ea3c1ace6
Author: Vladimir N. Makarov
Date: Fri May 10 09:15:50 2024 -0400
[PR114942][LRA]: Don't reuse input reload reg of inout early clobber operand
The insn in
https://gcc.gnu.org/g:e30211cb0b3a2b88959e9bc40626a17461de52de
commit r13-8740-ge30211cb0b3a2b88959e9bc40626a17461de52de
Author: Vladimir N. Makarov
Date: Thu Apr 4 16:04:04 2024 -0400
[PR114415][scheduler]: Fixing wrong code generation
For the test case, the insn scheduler
https://gcc.gnu.org/g:2f00e6caca1a14dfe26e94f608e9d79a787ebe08
commit r15-330-g2f00e6caca1a14dfe26e94f608e9d79a787ebe08
Author: Vladimir N. Makarov
Date: Wed May 8 10:39:04 2024 -0400
[PR114810][LRA]: Recognize alternatives with lack of available registers
for insn and demote them.
https://gcc.gnu.org/g:a24476422ba311b83737cf8bdc5892a7fc7514eb
commit r14-9793-ga24476422ba311b83737cf8bdc5892a7fc7514eb
Author: Vladimir N. Makarov
Date: Thu Apr 4 16:04:04 2024 -0400
[PR114415][scheduler]: Fixing wrong code generation
For the test case, the insn scheduler
https://gcc.gnu.org/g:9c91f8a88b2db50c8faf70786d3cef27b39ac9fc
commit r14-9557-g9c91f8a88b2db50c8faf70786d3cef27b39ac9fc
Author: Vladimir N. Makarov
Date: Tue Mar 19 16:57:11 2024 -0400
[PR99829][LRA]: Fixing LRA ICE on arm
LRA removed insn setting equivalence to memory whose
https://gcc.gnu.org/g:cebbaa2a84586a7345837f74a53b7a0263bf29ee
commit r14-9401-gcebbaa2a84586a7345837f74a53b7a0263bf29ee
Author: Vladimir N. Makarov
Date: Fri Mar 8 14:48:33 2024 -0500
[PR113790][LRA]: Fixing LRA ICE on riscv64
LRA failed to consider all insn alternatives when
On 9/7/23 07:21, senthilkumar.selva...@microchip.com wrote:
Hi,
One more execution failure for the avr target, this time from
gcc.c-torture/execute/bitfld-3.c.
Steps to reproduce
Enable LRA in avr.cc by removing TARGET_LRA_P hook, build with
$ make all-host && make
On 9/15/23 10:48, Vladimir Makarov wrote:
On 9/14/23 06:45, Surya Kumari Jangala wrote:
ira: Consider save/restore costs of callee-save registers [PR110071]
In improve_allocation() routine, IRA checks for each allocno if spilling
any conflicting allocnos can improve the allocation of this
On 9/14/23 06:45, Surya Kumari Jangala wrote:
ira: Consider save/restore costs of callee-save registers [PR110071]
In improve_allocation() routine, IRA checks for each allocno if spilling
any conflicting allocnos can improve the allocation of this allocno.
This routine computes the cost
I've committed the following patch. The reason for this patch is
explained in its commit message.
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit 3c834d85f2ec42c60995c2b678196a06cb744959
Author: Vladimir N. Makarov
Date: Thu Sep 14 10:26:48 2023
On 9/10/23 00:49, Hongyu Wang wrote:
Vladimir Makarov via Gcc-patches 于2023年9月9日周六 01:04写道：
On 8/31/23 04:20, Hongyu Wang wrote:
@@ -2542,6 +2542,8 @@ the code of the immediately enclosing expression
(@code{MEM} for the top level
of an address, @code{ADDRESS} for something that occurs
On 8/31/23 04:20, Hongyu Wang wrote:
@@ -2542,6 +2542,8 @@ the code of the immediately enclosing expression
(@code{MEM} for the top level
of an address, @code{ADDRESS} for something that occurs in an
@code{address_operand}). @var{index_code} is the code of the corresponding
index
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111225
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit f7bca44d97ad01b39f9d6e7809df7bf517eeb2fb
Author: Vladimir N. Makarov
Date: Thu Sep 7 09:59:10 2023 -0400
[LRA]:
On 9/7/23 02:23, Uros Bizjak wrote:
On Wed, Sep 6, 2023 at 9:43 PM Vladimir Makarov wrote:
On 9/1/23 05:07, Hongyu Wang wrote:
I think the approach proposed by Intel developers is better. In some way
we already use such approach when we pass memory mode to get the base
reg class.
On 9/1/23 05:07, Hongyu Wang wrote:
Uros Bizjak via Gcc-patches 于2023年8月31日周四 18:16写道：
On Thu, Aug 31, 2023 at 10:20 AM Hongyu Wang wrote:
From: Kong Lingling
Current reload infrastructure does not support selective base_reg_class
for backend insn. Add insn argument to base_reg_class for
On 8/17/23 07:19, senthilkumar.selva...@microchip.com wrote:
On Wed, 2023-08-16 at 12:13 -0400, Vladimir Makarov wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
The attached patch fixes recently found wrong insn removal in LRA port
for AVR.
The following patch fixes a problem with allocating the same stack slots
to conflicting pseudos. The problem exists only for AVR LRA port.
The patch was successfully bootstrapped and tested on x86-64 and aarch64.
commit c024867d1aa9d465e0236fc9d45d8e1d4bb6bd30
Author: Vladimir N. Makarov
The attached patch fixes recently found wrong insn removal in LRA port
for AVR.
The patch was successfully tested and bootstrapped on x86-64 and aarch64.
commit 748a77558ff37761faa234e19327ad1decaace33
Author: Vladimir N. Makarov
Date: Wed Aug 16 09:13:54 2023 -0400
[LRA]: Spill
The patch fixes a failure of building aarch64 port with my yesterday patch.
The patch was successfully bootstrapped on x86-64 and aarch64.
commit c4760c0161f92b92361feba11836e3d066bb330c
Author: Vladimir N. Makarov
Date: Mon Aug 14 16:06:27 2023 -0400
[LRA]: Process output stack pointer
On 8/14/23 14:37, Prathamesh Kulkarni wrote:
On Mon, 14 Aug 2023 at 06:39, Vladimir Makarov via Gcc-patches
wrote:
The following patch fixes useless asserts in my latest patch
implementing output stack pointer reloads.
Hi Vladimir,
It seems that this patch caused the following ICE
The following patch fixes useless asserts in my latest patch
implementing output stack pointer reloads.
commit 18b417fe1a46d37738243267c1f559cd0acc4886
Author: Vladimir N. Makarov
Date: Sun Aug 13 20:54:58 2023 -0400
[LRA]: Fix asserts for output stack pointer reloads
The patch
On 8/10/23 07:33, senthilkumar.selva...@microchip.com wrote:
Hi Vlad,
I can confirm your commit
(https://gcc.gnu.org/git?p=gcc.git;a=commit;h=2971ff7b1d564ac04b537d907c70e6093af70832)
fixes the above problem, thank you. However, I see execution failures if a
pseudo assigned to FP
Sorry, I had some problems with email. Therefore there are email
duplication and they were sent to g...@gcc.gnu.org instead of
gcc-patches@gcc.gnu.org
On 8/9/23 16:54, Vladimir Makarov wrote:
On 8/9/23 07:15, senthilkumar.selva...@microchip.com wrote:
Hi,
After turning on FP -> SP
On 8/9/23 16:54, Vladimir Makarov wrote:
On 8/9/23 07:15, senthilkumar.selva...@microchip.com wrote:
Hi,
After turning on FP -> SP elimination after Vlad fixed
an elimination issue in
https://gcc.gnu.org/git?p=gcc.git;a=commit;h=2971ff7b1d564ac04b537d907c70e6093af70832,
I'm now
On 8/9/23 16:54, Vladimir Makarov wrote:
On 8/9/23 07:15, senthilkumar.selva...@microchip.com wrote:
Hi,
After turning on FP -> SP elimination after Vlad fixed
an elimination issue in
https://gcc.gnu.org/git?p=gcc.git;a=commit;h=2971ff7b1d564ac04b537d907c70e6093af70832,
I'm now
On 8/9/23 07:15, senthilkumar.selva...@microchip.com wrote:
Hi,
After turning on FP -> SP elimination after Vlad fixed
an elimination issue in
https://gcc.gnu.org/git?p=gcc.git;a=commit;h=2971ff7b1d564ac04b537d907c70e6093af70832,
I'm now running into reload failure if arithmetic is
On 8/7/23 09:18, Richard Biener wrote:
On Wed, 2 Aug 2023, Richard Biener wrote:
On Mon, 31 Jul 2023, Jeff Law wrote:
On 7/31/23 04:54, Richard Biener via Gcc-patches wrote:
On Tue, 25 Jul 2023, Richard Biener wrote:
The following applies a micro-optimization to find_hard_regno_for_1,
The following patch fixes a problem found by LRA port for avr target.
The problem description is in the commit message.
The patch was successfully bootstrapped and tested on x86-64 and aarch64.
commit abf953042ace471720c1dc284b5f38e546fc0595
Author: Vladimir N. Makarov
Date: Fri Aug 4
On 7/17/23 07:33, senthilkumar.selva...@microchip.com wrote:
Hi,
The avr target has a bunch of patterns that directly set hard regs at expand
time, like so
(define_expand "cpymemhi"
[(parallel [(set (match_operand:BLK 0 "memory_operand" "")
(match_operand:BLK 1
On 8/1/23 01:20, Surya Kumari Jangala wrote:
Ping
Sorry for delay with the answer. I was on vacation.
On 21/07/23 3:43 pm, Surya Kumari Jangala via Gcc-patches wrote:
The improve_allocation() routine does not update the
allocated_hardreg_p[] array after an allocno is assigned a register.
On 7/25/23 09:40, Richard Biener wrote:
The following removes the code checking whether a noop copy
is between something involved in the return sequence composed
of a SET and USE. Instead of checking for this special-case
the following makes us only ever remove noop copies between
pseudos -
The following patch fixes sparc solaris bootstrap. The explanation of
the patch is in the commit message.
The patch was successfully bootstrap on x86-64, aarch64, and sparc64
solaris.
commit d17be8f7f36abe257a7d026dad61e5f8d14bdafc
Author: Vladimir N. Makarov
Date: Fri Jul 21 20:28:50
On 7/20/23 16:45, Rainer Orth wrote:
Hi Vladimir,
The following patch is necessary for porting avr to LRA.
The patch was successfully bootstrapped and tested on x86-64, aarch64, and
ppc64le.
There is still avr poring problem with reloading of subreg of frame
pointer. I'll address it later
On 7/20/23 07:17, senthilkumar.selva...@microchip.com wrote:
Hi,
The avr backend has this define_insn_and_split
(define_insn_and_split "*tablejump_split"
[(set (pc)
(unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r,z")]
UNSPEC_INDEX_JMP))
(use
The following patch improves code for avr LRA port. More explanation
for the patch can be found in the commit message.
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit 4b8878fbf7b74ea5c3405c9f558df0517036f131
Author: Vladimir N. Makarov
Date: Thu
The following patch is necessary for porting avr to LRA.
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
There is still avr poring problem with reloading of subreg of frame
pointer. I'll address it later on this week.
commit
On 7/17/23 03:17, senthilkumar.selva...@microchip.com wrote:
On Fri, 2023-07-14 at 09:29 -0400, Vladimir Makarov wrote:
If you send me the preprocessed test, I could start to work on it to fix
the problems. I think it is hard to fix them right for a person having
a little experience with
On 7/13/23 05:27, SenthilKumar.Selvaraj--- via Gcc wrote:
Hi,
I've been spending some (spare) time checking what it would take to
make LRA work for the avr target.
Right after I removed the TARGET_LRA_P hook disabling LRA, building
libgcc failed with a weird ICE.
On the avr,
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109520
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit b175b4887f928118af997f6d4d75097a64dcec5d
Author: Vladimir N. Makarov
Date: Thu Jul 13 10:42:17 2023 -0400
On 7/12/23 07:05, senthilkumar.selva...@microchip.com wrote:
Hi,
I've been spending some (spare) time trying to get LRA working
for the avr target.
Thank you for addressing this problem.
The code you changing is very sensitive and was a source of multiple PRs
in the past. But I
On 7/12/23 12:22, Richard Sandiford wrote:
Vladimir Makarov writes:
On 7/12/23 06:07, Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
index 73fbef29912..2f95121df06 100644
--- a/gcc/lra-assigns.cc
+++ b/gcc/lra
On 7/12/23 06:07, Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
index 73fbef29912..2f95121df06 100644
--- a/gcc/lra-assigns.cc
+++ b/gcc/lra-assigns.cc
@@ -1443,10 +1443,11 @@ assign_by_spills (void
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110372
The patch was successfully bootstrapped and tested on x86-64.
commit 1f7e5a7b91862b999aab88ee0319052aaf00f0f1
Author: Vladimir N. Makarov
Date: Fri Jul 7 09:53:38 2023 -0400
LRA: Refine reload pseudo class
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110215
The patch was successfully tested and bootstrapped on x86-64, aarch64,
and ppc64le.
It is difficult to make a stable test for the PR. So there is not test
in the patch.
commit
On 6/7/23 12:20, Jeff Law wrote:
On 6/7/23 09:35, Vladimir Makarov via Gcc-patches wrote:
The following patch fixes
-ENOPATCH
Sorry, here is the patch.
commit 08ca31fb27841cb7f3bff7086be6f139136be1a7
Author: Vladimir N. Makarov
Date: Wed Jun 7 09:51:54 2023 -0400
RA: Constrain
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
The patch was successfully bootstrapped and tested on x86-64, aarcha64,
and ppc64le.
The following patch fixes an LRA bug triggered by switching H8300 target
from reload to LRA. The description of the problem is in the commit
message.
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit 30038a207c10a2783fa2695b62c7c8458ef05e73
Author:
On 5/17/23 02:57, liuhongt wrote:
r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost
calculation when the preferred register class are not known yet.
It regressed powerpc PR109610 and PR109858, it looks too aggressive to use
NO_REGS when mode can be allocated with GENERAL_REGS.
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
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
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
On 4/19/23 14:53, Surya Kumari Jangala wrote:
...
I have a few queries:
1. A zero cost seems strange for the regs r14-r31. If using a reg in the
set [14..31] has zero cost, then why wasn’t such a reg chosen for r118
in the first place, instead of r3?
I guess it is because assign_hard_reg
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
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
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
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=108999
The patch was successfully bootstrapped and tested on i686, x86-64,
aarch64, and ppc64 be/le.
commit 3c75631fc09a22f2513fab80ef502c2a8b0f9121
Author: Vladimir N. Makarov
Date: Thu Mar 9 08:41:09 2023 -0500
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
The patch was successfully bootstrapped and tested on i686, x86-64,
aarch64, ppc64le.
commit 23661e39df76e07fb4ce1ea015379c7601d947ef
Author: Vladimir N. Makarov
Date: Thu Mar 2 16:29:05 2023 -0500
IRA: Use
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774
The patch was successfully bootstrapped and tested on i686, x86_64, and
aarch64.
commit a33e3dcbd15e73603796e30b5eeec11a0c8bacec
Author: Vladimir N. Makarov
Date: Mon Feb 13 16:05:04 2023 -0500
RA: Clear
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
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
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
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
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:
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:
The following patch solves a spill problem for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
There are still redundant moves which should be removed to solve PR.
I'll continue my work on this in Jan.
commit 12abd5a7d13209f79664ea603b3f3517f71b8c4f
Author: Vladimir N. Makarov
Date:
On 2022-12-09 14:23, Georg-Johann Lay wrote:
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
I am sorry, I feel your frustration. I was not aware of this PR.
Unfortunately, the PR was marked as P4 and I have too many open PRs and
should prioritize them.
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
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
On 2022-10-25 06:01, Torbjörn SVENSSON wrote:
In commit 081c96621da, the call to resize_reg_info() was moved before
the call to remove_scratches() and the latter one can increase the
number of regs and that would cause an out of bounds usage on the
reg_renumber global array.
Without this
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've
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
On 2022-05-05 02:52, Alexandre Oliva wrote:
Regstrapped on x86_64-linux-gnu and ppc64le-linux-gnu, also tested
targeting ppc- and ppc64-vx7r2. Ok to install?
I am ok with the modified version of the patch. It looks reasonable for
me and I support its commit.
But I think I can not
On 2022-03-30 15:18, Uros Bizjak wrote:
On Wed, Mar 30, 2022 at 7:15 PM Vladimir Makarov via Gcc-patches
wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
The patch was successfully bootstrapped and tested on x86-64.
diff --git a/gcc/testsuite/gcc.target
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
The patch was successfully bootstrapped and tested on x86-64.
commit 25de4889c16fec80172a5e2d1825f3ff505d0cc4
Author: Vladimir N. Makarov
Date: Wed Mar 30 13:03:44 2022 -0400
[PR105032] LRA: modify loop
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
The PR was already fixed by Jakub but his patch did not fix a latent LRA
bug mentioned in the PR comments. The current patch fixes the latent bug.
The patch was successfully bootstrapped and tested on x86-64 and
On 2022-03-23 07:49, Richard Biener wrote:
form_threads_from_copies processes a sorted array of copies, skipping
those with the same thread and conflicting threads and merging the
first non-conflicting ones. After that it terminates the loop and
gathers the remaining elements of the array,
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961
The patch was successfully bootstrapped and tested on x86-64.
commit 4e2291789a8b31c550271405782356e8aeddcee3
Author: Vladimir N. Makarov
Date: Fri Mar 18 14:23:40 2022 -0400
[PR104961] LRA: split hard reg
On 2022-03-12 14:37, Jakub Jelinek wrote:
Hi!
The following testcase ICEs on powerpc-linux, because lra_substitute_pseudo
substitutes (const_int 1) into a subreg operand. First a subreg of subreg
of a reg appears in a debug insn (which surely is invalid outside of
debug insns, but in debug
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074
The patch was successfully bootstrapped and tested on x86-64 and aarch64.
commit d8e5fff6b74b82c2ac3254be9a1f0fb6b30dbdbf
Author: Vladimir N. Makarov
Date: Thu Mar 10 16:16:00 2022 -0500
[PR103074] LRA:
On 2022-03-02 07:25, Alexandre Oliva wrote:
Regstrapped on x86_64-linux-gnu, also tested on various riscv and arm
targets (with gcc-11). Ok to install?
Yes.
Thank you on working this, Alex.
for gcc/ChangeLog
* lra-constraints.cc (undo_optional_reloads): Recognize and
On 2022-03-02 03:58, Richard Biener wrote:
In this PR allocnos_conflict_p takes 90% of the compile-time via
the calls from update_conflict_hard_regno_costs. This is due to
the high number of conflicts recorded in the dense bitvector
representation. Fortunately we can take advantage of the
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
commit ec1b9ba2d7913fe5e9deacc8e55e7539262f5124
Author: Vladimir N. Makarov
Date: Mon Feb 28 16:43:50 2022 -0500
[PR104637]
On 2022-02-25 09:14, Richard Biener wrote:
The following replaces
/* Skip bits that are zero. */
for (; (word & 1) == 0; word >>= 1)
bit_num++;
idioms in ira-int.h in the attempt to speedup update_conflict_hard_regno_costs
which we're bound on in PR104686. The
On 2022-02-20 12:34, Iain Sandoe wrote:
^^^ this is mostly for my education - the stuff below is a potential solution
to leaving lra-constraints unchanged and fixing the Darwin bug….
I'd be really glad if you do manage to fix this w/o changing LRA.
Richard has a legitimate point that my
The patch solves the following PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104447
The patch was successfully bootstrapped and tested on x86-64.
commit db69f666a728ce800a840115829f6b64bc3174d2
Author: Vladimir N. Makarov
Date: Thu Feb 17 11:31:50 2022 -0500
[PR104447] LRA: Do not
On 2022-02-14 11:00, Richard Sandiford wrote:
Hi Vlad,
Vladimir Makarov via Gcc-patches writes:
Hi, Richard. Change LRA is mine and I approved it for Iain's patch.
I think there is no need for this code and it is misleading. If
'mem[low_sum]' does not work, I don't think that 'reg
On 2022-02-14 04:44, Richard Sandiford via Gcc-patches wrote:
Iain Sandoe via Gcc-patches writes:
Two issues resulted in this PR, which manifests when we force a constant into
memory in LRA (in PIC code on Darwin). The presence of such forced constants
is quite dependent on other RTL
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
The patch was successfully tested and bootstrapped on x86-64 and aarch64.
commit 274a4d29421e73c9b40c1641986c6ed904e20184
Author: Vladimir N. Makarov
Date: Fri Feb 11 09:52:14 2022 -0500
[PR104400] LRA:
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676
The patch was successfully bootstrapped and tested on x86_64, aarch64,
and ppc64.
commit 85419ac59724b7ce710ebb4acf03dbd747edeea3
Author: Vladimir N. Makarov
Date: Fri Jan 21 13:34:32 2022 -0500
[PR103676]
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
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
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-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
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
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: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)
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
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
1 - 100 of 197 matches
Mail list logo
