Hi all,
I'm trying to solve an infinite loop in the "reload" pass (LRA). I need
early-clobber on my load instructions and it goes wrong when register
pressure is high.
Is there a proper way to fix this? Or do I need to do something "hacky"
like fixing a register for use with reloads?
Here'
this.
It could be connected. both things should not happen.
This is now confirmed to be unrelated: the instruction moving values
from the new registers to the old must be followed by a no-op in certain
instruction combinations due to GCN having only partial hardware
dependency detection.
Th
On 11/10/2023 09:58, Andrew Stubbs wrote:
> On 11/10/2023 07:54, Chung-Lin Tang wrote:
>>
>>
>> On 2023/10/10 11:11 PM, Andrew Stubbs wrote:
>>> Hi all,
>>>
>>> I'm trying to add a new register set to the GCN port, but I've hit a
>>> problem I don't understand.
>>>
>>> There are 256 new registers (
On 11/10/2023 07:54, Chung-Lin Tang wrote:
On 2023/10/10 11:11 PM, Andrew Stubbs wrote:
Hi all,
I'm trying to add a new register set to the GCN port, but I've hit a
problem I don't understand.
There are 256 new registers (each 2048 bit vector register) but the
register file has to be divided
On 10/10/2023 20:09, Segher Boessenkool wrote:
Hi Andrew,
On Tue, Oct 10, 2023 at 04:11:18PM +0100, Andrew Stubbs wrote:
I'm also seeing wrong-code bugs when I allow more than 32 new registers,
but that might be an unrelated problem. Or the allocation is broken? I'm
still analyzing this.
I
On 2023/10/10 11:11 PM, Andrew Stubbs wrote:
> Hi all,
>
> I'm trying to add a new register set to the GCN port, but I've hit a
> problem I don't understand.
>
> There are 256 new registers (each 2048 bit vector register) but the
> register file has to be divided between all the running hard
Hi Andrew,
On Tue, Oct 10, 2023 at 04:11:18PM +0100, Andrew Stubbs wrote:
> I'm also seeing wrong-code bugs when I allow more than 32 new registers,
> but that might be an unrelated problem. Or the allocation is broken? I'm
> still analyzing this.
It could be connected. both things should not
Hi all,
I'm trying to add a new register set to the GCN port, but I've hit a
problem I don't understand.
There are 256 new registers (each 2048 bit vector register) but the
register file has to be divided between all the running hardware
threads; if you can use fewer registers you can get mo
__absvsi2() function is clumsy and quite
BAD: GCC should generate the same code as for the __absvdi2() function,
using the 32-bit registers instead of the 64-bit registers.
5. The register allocation in the __abswsi2() and __abswdi2() functions
is BAD; the LEA instruction should b
I have a question about process_bb_lives and check_pseudos_live_through_calls.
I am trying to optimize aarch64 vector functions, which do not partially
clobber vector registers the way that 'normal' functions do. To do this
I am looking at modifying the hard_regno_call_part_clobbered target
funct
On Dec 18, 2017, at 19:03, Leslie Zhai
mailto:lesliez...@llvm.org.cn>
<mailto:lesliez...@llvm.org.cn
<mailto:lesliez...@llvm.org.cn>>> wrote:
Hi Leslie,
As others have pointed out, the notion that register
alloca
ISCV targets, and I just want to learn and
> practice HEA in RA, thanks for your sharing.
>
>
> 在 2017年12月21日 01:25, Jakob Stoklund Olesen 写道:
>
>>
>> On Dec 18, 2017, at 19:03, Leslie Zhai >> lesliez...@llvm.org.cn>> wrote:
>>>
>>
>> Hi Le
ote:
Hi Leslie,
As others have pointed out, the notion that register allocation is
isomorphic to graph coloring is poppycock. There are other important
aspects, in particular the placement of spill/fill/copy instructions.
The importance of graph coloring relative to spill code placement
depen
> On Dec 18, 2017, at 19:03, Leslie Zhai wrote:
Hi Leslie,
As others have pointed out, the notion that register allocation is isomorphic
to graph coloring is poppycock. There are other important aspects, in
particular the placement of spill/fill/copy instructions. The importance of
gr
> On Dec 18, 2017, at 8:16 PM, Vladimir Makarov via llvm-dev
> wrote:
>
>
>
> On 12/18/2017 07:07 PM, Michael Clark wrote:
>> Hi Leslie,
>>
>> I suggest adding these 3 papers to your reading list.
>>
>> Register allocation for programs
On 12/18/2017 07:07 PM, Michael Clark wrote:
Hi Leslie,
I suggest adding these 3 papers to your reading list.
Register allocation for programs in SSA-form
Sebastian Hack, Daniel Grund, and Gerhard Goos
http://www.rw.cdl.uni-saarland.de/~grund/papers/cc06-ra_ssa.pdf
*when* memory is worse than a
register. It may very well be the case that leaving something in memory
frees up a register for something much more important to use it. All of
the register allocation algorithms try to determine this kind of thing
through various heuristics. Which heuristic is most ef
your reading list.
Register allocation for programs in SSA-form
Sebastian Hack, Daniel Grund, and Gerhard Goos
http://www.rw.cdl.uni-saarland.de/~grund/papers/cc06-ra_ssa.pdf
Simple and Efficient Construction of Static Single Assignment Form
Matthias Braun , Seba
Hi Leslie,
I suggest adding these 3 papers to your reading list.
Register allocation for programs in SSA-form
Sebastian Hack, Daniel Grund, and Gerhard Goos
http://www.rw.cdl.uni-saarland.de/~grund/papers/cc06-ra_ssa.pdf
Simple and Efficient Construction of
or VLIW processors? I don't have experienced on them,
> please teach me.
I do not have much experience with those architectures either. As I
said, the "best" algorithm for register allocation is very
target-dependent. What works well on AVR might work very poorly on a
GPU. The only way
ferent strategies to determine *when* memory is worse than a
register. It may very well be the case that leaving something in memory
frees up a register for something much more important to use it. All of
the register allocation algorithms try to determine this kind of thing
through variou
Since there are tradeoffs involved, one needs to
evaluate different strategies to determine *when* memory is worse than a
register. It may very well be the case that leaving something in memory
frees up a register for something much more important to use it. All of
the register allocation algori
On 12/14/17 9:18 PM, Leslie Zhai wrote:
> * The papers by Briggs and Chaiten contradict[2] themselves when examine
> the text of the paper vs. the pseudocode provided?
I've read both of these papers many times (in the past) and I don't recall
any contradictions in them. Can you (Dave?) be more sp
Hi Vladimir,
Thanks for your kind and very detailed response!
在 2017年12月15日 12:40, Vladimir Makarov 写道:
On 12/14/2017 10:18 PM, Leslie Zhai wrote:
Hi GCC and LLVM developers,
I am learning Register Allocation algorithms and I am clear that:
* Unlimited VirtReg (pseudo) -> limited
On 12/14/2017 10:18 PM, Leslie Zhai wrote:
Hi GCC and LLVM developers,
I am learning Register Allocation algorithms and I am clear that:
* Unlimited VirtReg (pseudo) -> limited or fixed or alias[1] PhysReg
(hard)
* Memory (20 - 100 cycles) is expensive than Register (1 cycle), but
it
Hi GCC and LLVM developers,
I am learning Register Allocation algorithms and I am clear that:
* Unlimited VirtReg (pseudo) -> limited or fixed or alias[1] PhysReg (hard)
* Memory (20 - 100 cycles) is expensive than Register (1 cycle), but it
has to spill code when PhysReg is unavaila
On 07/24/2017 11:37 AM, Georg-Johann Lay wrote:
> Andrew Stubbs schrieb:
>> On 24/07/17 14:58, Georg-Johann Lay wrote:
>>> Dunno if that works in all situation. For example, when the register
>>> allocator is facing high register pressure and decides to spill the
>>> target register, it uses the c
Andrew Stubbs schrieb:
On 24/07/17 14:58, Georg-Johann Lay wrote:
Dunno if that works in all situation. For example, when the register
allocator is facing high register pressure and decides to spill the
target register, it uses the constraints of the matched insn.
That would be a memory to me
On 24/07/17 14:58, Georg-Johann Lay wrote:
Dunno if that works in all situation. For example, when the register
allocator is facing high register pressure and decides to spill the
target register, it uses the constraints of the matched insn.
That would be a memory to memory move, and therefore
On 24.07.2017 13:38, Andrew Stubbs wrote:
Thanks to all those who replied. :-)
Here's what I've done to fix the problem:
1. Set the base rclass to A only.
2. Configured secondary reloads to B via A.
3. Disabled the Rb constraint. [*]
That's enough to create correct code, but it's pretty horr
Thanks to all those who replied. :-)
Here's what I've done to fix the problem:
1. Set the base rclass to A only.
2. Configured secondary reloads to B via A.
3. Disabled the Rb constraint. [*]
That's enough to create correct code, but it's pretty horrible, so I
also added new patterns of the
On 07/21/2017 12:40 PM, Nathan Sidwell wrote:
> On 07/21/2017 07:50 AM, Andrew Stubbs wrote:
>
>> (set (match_operand:SI "register_operand" "=a,b")
>> (match_operand:SI "memory_operand" "Ra,Rb"))
>
>
> How horrible would it be to split expose the entire mem:
>
> (set (match_operand:SI "
On 21/07/17 19:40, Nathan Sidwell wrote:
> On 07/21/2017 07:50 AM, Andrew Stubbs wrote:
>
>> (set (match_operand:SI "register_operand" "=a,b")
>> (match_operand:SI "memory_operand" "Ra,Rb"))
>
>
> How horrible would it be to split expose the entire mem:
>
> (set (match_operand:SI "regis
On 07/21/2017 07:50 AM, Andrew Stubbs wrote:
(set (match_operand:SI "register_operand" "=a,b")
(match_operand:SI "memory_operand" "Ra,Rb"))
How horrible would it be to split expose the entire mem:
(set (match_operand:SI "register" "=a,b")
(mem:SI (match_operand:SI "register" "a,
Andrew Stubbs schrieb:
Hi all,
I have an architecture that has two register files. Let's call them
class A and class B. There are some differences between their
capabilities, but for the purposes of this problem, they can be
considered to be identical, both holding SImode values, and both abl
On 07/21/2017 05:50 AM, Andrew Stubbs wrote:
> Hi all,
>
> I have an architecture that has two register files. Let's call them
> class A and class B. There are some differences between their
> capabilities, but for the purposes of this problem, they can be
> considered to be identical, both holdin
Hi all,
I have an architecture that has two register files. Let's call them
class A and class B. There are some differences between their
capabilities, but for the purposes of this problem, they can be
considered to be identical, both holding SImode values, and both able to
receive values wit
On Tue, Oct 13, 2015 at 11:06:48AM -0600, Jeff Law wrote:
> On 10/13/2015 07:12 AM, Dominik Vogt wrote:
> >In some cases, the work of the cse1 pass is counterproductive, as
> >we noticed on s390x. The effect described below is present since
> >at least 4.8.0. Note that this may not become manifes
On 10/22/2015 09:08 AM, Vladimir Makarov wrote:
On 10/22/2015 06:05 AM, Dominik Vogt wrote:
On Tue, Oct 13, 2015 at 05:03:36PM -0400, Vladimir Makarov wrote:
[snip]
I checked my article
ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
and GVN gave mostly 0.2% on eon on
On 10/22/2015 06:05 AM, Dominik Vogt wrote:
On Tue, Oct 13, 2015 at 05:03:36PM -0400, Vladimir Makarov wrote:
[snip]
I checked my article
ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
and GVN gave mostly 0.2% on eon only. The current environment is
quite different (
On Tue, Oct 13, 2015 at 05:03:36PM -0400, Vladimir Makarov wrote:
[snip]
> I checked my article
>
> ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
>
> and GVN gave mostly 0.2% on eon only. The current environment is
> quite different (IRA, LRA) so the results might be d
On 10/13/2015 03:03 PM, Vladimir Makarov wrote:
I checked my article
ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
and GVN gave mostly 0.2% on eon only. The current environment is quite
different (IRA, LRA) so the results might be different too.
Yea, but if anyth
On 10/13/2015 01:06 PM, Jeff Law wrote:
On 10/13/2015 07:12 AM, Dominik Vogt wrote:
In some cases, the work of the cse1 pass is counterproductive, as
we noticed on s390x. The effect described below is present since
at least 4.8.0. Note that this may not become manifest in a
performance issue p
On 10/13/2015 07:12 AM, Dominik Vogt wrote:
In some cases, the work of the cse1 pass is counterproductive, as
we noticed on s390x. The effect described below is present since
at least 4.8.0. Note that this may not become manifest in a
performance issue problem on all platforms. Also note that
In some cases, the work of the cse1 pass is counterproductive, as
we noticed on s390x. The effect described below is present since
at least 4.8.0. Note that this may not become manifest in a
performance issue problem on all platforms. Also note that -O1
does not show this behaviour because the r
will
be the new Unrolling degree.
This new unrolling degree will lead to better register allocation and reduction
of register pressure and because the destination registers is
Shared between different iterations because of no dependency as described by
the Data dependency distance given in DDG
Hello All:
I was going through the following article
" Register Allocation with instruction scheduling: a new approach" by Pinter
etal.
The phase ordering of register allocation and Instruction scheduling is
important topic. The scheduling before register allocator
increases th
ailto:wdijk...@arm.com]
> Sent: 27 August 2014 17:25
> To: 'gcc@gcc.gnu.org'
> Subject: Register allocation: caller-save vs spilling
>
> Hi,
>
> I'm investigating various register allocation inefficiencies. The first thing
> that stands out
> is that GCC bot
Hi,
I'm investigating various register allocation inefficiencies. The first thing
that stands out is
that GCC both supports caller-saves as well as spilling. Spilling seems to
spill all definitions and
all uses of a liverange. This means you often end up with multiple reloads
close tog
memory while
having GCC recognize that they are not 'normal' registers that you can
do operations on and should not be part of the normal register
allocation scheme.
Steve Ellcey
Steve Ellcey writes:
> On Wed, 2013-02-27 at 22:28 +, Richard Sandiford wrote:
>> FWIW, after seeing that, I tried the patch below. Disabling
>> ADJUST_REG_ALLOC_ORDER seemed to be a very mixed bag sizewise though --
>> certainly not the consistent win that I hoped -- and I wasn't set up to
>
On Wed, 2013-02-27 at 22:28 +, Richard Sandiford wrote:
> FWIW, after seeing that, I tried the patch below. Disabling
> ADJUST_REG_ALLOC_ORDER seemed to be a very mixed bag sizewise though --
> certainly not the consistent win that I hoped -- and I wasn't set up to
> do proper speed testing.
"Steve Ellcey " writes:
> I was looking at MIPS register allocation and I noticed an odd thing.
> There is a definition of REG_ALLOC_ORDER in mips.h but in
> mips_order_regs_for_local_alloc (mips.c), we do not use this ordering,
> we just have:
>
> for (i = 0;
I was looking at MIPS register allocation and I noticed an odd thing.
There is a definition of REG_ALLOC_ORDER in mips.h but in
mips_order_regs_for_local_alloc (mips.c), we do not use this ordering,
we just have:
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
reg_alloc_order[i] = i;
I
l be probably most general base problem. Now you can simplify
this model in different ways. But don't simplify it to much as ,for
example, just solving register allocation (assignment) with ILP has no
sense as graph coloring heuristics based on Kempe's criterion of trivial
colorabi
seems that no heuristic algorithm can even get close to
an optimal register
allocation. A heuristic algorithm can't take all effects and
side-effects into account
simultaneously.
Considering all that, why GCC does not use generic optimization
algorithms for RA?
A generic optimization can tak
re puzzled. The RA
stuff is very complicated,
having many constraints and many dependencies with other passes.
Taking this into
account, it seems that no heuristic algorithm can even get close to an
optimal register
allocation. A heuristic algorithm can't take all effects and
side-effects i
having many constraints and many dependencies with other passes. Taking
this into
account, it seems that no heuristic algorithm can even get close to an
optimal register
allocation. A heuristic algorithm can't take all effects and
side-effects into account
simultaneously.
Considering a
On 02/13/2013 11:24 PM, Edgar E. Iglesias wrote:
On Thu, Feb 14, 2013 at 12:36:46AM +0100, Michael Eager wrote:
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2
On Thu, Feb 14, 2013 at 12:36:46AM +0100, Michael Eager wrote:
> On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
> > On 13-02-13 1:36 AM, Michael Eager wrote:
> >> Hi --
> >>
> >> I'm seeing register allocation problems and code size increases
> >>
On 13-02-13 6:36 PM, Michael Eager wrote:
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled usin
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same comparison and similar computation.
On Mon, Jun 4, 2012 at 1:44 AM, Richard Sandiford
wrote:
> Klaus Pedersen writes:
[...]
>> My original fix, that use sane cost for the ACC_REGS: gpr_acc_cost_3.patch
>
> Why sane? Transfers from and (especially) to HI and LO really are
> expensive on many processors. Obviously it'd be nice at s
Klaus Pedersen writes:
> On Tue, May 29, 2012 at 6:55 AM, Vladimir Makarov wrote:
>> On 05/28/2012 03:09 PM, Richard Sandiford wrote:
>>>
>>> Klaus Pedersen writes:
The summery goes something like this:
It is possible for the second pass of ira to get confused and decide that
On Tue, May 29, 2012 at 6:55 AM, Vladimir Makarov wrote:
> On 05/28/2012 03:09 PM, Richard Sandiford wrote:
>>
>> Klaus Pedersen writes:
>>>
>>> The summery goes something like this:
>>>
>>> It is possible for the second pass of ira to get confused and decide that
>>> NO_REGS or a hard float regi
On 05/30/2012 10:27 PM, Klaus Pedersen wrote:
Thanks for the pointer,
On Wed, May 30, 2012 at 2:40 AM, Vladimir Makarov wrote:
Here is an extract from my article from GCC Summit 2004 proceedings.
It is interesting to note that the pass also implicitly does code
selection. Regclass works in
Thanks for the pointer,
On Wed, May 30, 2012 at 2:40 AM, Vladimir Makarov wrote:
> Here is an extract from my article from GCC Summit 2004 proceedings.
>
> It is interesting to note that the pass also implicitly does code
> selection. Regclass works in two passes. On the first pass, it
> defin
On 05/29/2012 02:33 AM, Richard Sandiford wrote:
Hi Vlad,
Thanks for the answer.
Vladimir Makarov writes:
On 05/28/2012 03:09 PM, Richard Sandiford wrote:
Or is it a conceptual part of the algorithm?
No.
More generally,
what kind of situations does the second pass help with?
I can
Hi Vlad,
Thanks for the answer.
Vladimir Makarov writes:
> On 05/28/2012 03:09 PM, Richard Sandiford wrote:
>>Or is it a conceptual part of the algorithm?
> No.
>>More generally,
>> what kind of situations does the second pass help with?
> I can not show such situations right now but I d
On 05/28/2012 03:09 PM, Richard Sandiford wrote:
Klaus Pedersen writes:
The summery goes something like this:
It is possible for the second pass of ira to get confused and decide that
NO_REGS or a hard float register are better choices for the result of the
2 operand mult. First pass already o
Klaus Pedersen writes:
> The summery goes something like this:
>
> It is possible for the second pass of ira to get confused and decide that
> NO_REGS or a hard float register are better choices for the result of the
> 2 operand mult. First pass already optimally allocated in GR_AND_MD1_REGS.
Yea
On May 14, 2012, at 5:47 PM, Joern Rennecke wrote:
> Quoting paul_kon...@dell.com:
>
>> I'm running into an ICE due to what looks like wrong register allocation,
>> and I'm trying to figure out where the problem lies. It shows up with
>> today's GCC
Quoting paul_kon...@dell.com:
I'm running into an ICE due to what looks like wrong register
allocation, and I'm trying to figure out where the problem lies. It
shows up with today's GCC (trunk). I haven't yet tried to narrow
it down to a particular change.
It s
I'm running into an ICE due to what looks like wrong register allocation, and
I'm trying to figure out where the problem lies. It shows up with today's GCC
(trunk). I haven't yet tried to narrow it down to a particular change.
It shows up in the pdp11 target, -O2. No
The summery goes something like this:
It is possible for the second pass of ira to get confused and decide that
NO_REGS or a hard float register are better choices for the result of the
2 operand mult. First pass already optimally allocated in GR_AND_MD1_REGS.
Two pass ira is enabled with "-fexpe
On 11/22/2011 12:11 PM, Bodart, Mitch L wrote:
> Unfortunately the source change suggestion didn't work, but that's OK because
> I can make the asm work by eliminating some register pressure.
Hmm. Well, if you keep that "memory" clobber there, you don't actually
need to represent the RW memory a
the answer is no, or atleast, nothing that's going to be fixed
anytime soon.
thanks again!
Mitch
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Tuesday, November 22, 2011 11:35 AM
> To: Bodart, Mitch L
> Cc: gcc@gcc.gnu.org
> Subject:
On 11/22/2011 10:55 AM, Bodart, Mitch L wrote:
> What aspect of inline asm processing is preventing gcc from allocating
> register eax to both %0 and %1's address in the following test case?
>
> gcc -m32 -S foo.c
> foo.c: In function 'foo':
> foo.c:20: error: can't find a register in c
Hello colleagues,
I've come across a suspicious error with inline asm and register allocation,
and am looking for a clarification of the rules.
What aspect of inline asm processing is preventing gcc from allocating
register eax to both %0 and %1's address in the following test case
tter suited in this group)
>
> --
> PMatos
>
>
>
--
View this message in context:
http://old.nabble.com/register-allocation-in-gcc-tp32672242p32676590.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
On 18/10/11 06:12, vikramsp wrote:
In my .md file there is an insn
(define_insn abssf2
(clobber (match_scratch 2 ""))
the %2 register is allocated as r0 in the real code.
My problem is that i want other than r0 to be allocated
for operand 2.
Please help how to do t
in context:
http://old.nabble.com/register-allocation-in-gcc-tp32672242p32672242.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
On 07/17/2011 08:26 PM, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
promoted Vladimir Makarov to Register Allocation Maintainer.
Please join me in congratulating Vlad.
Please update your listing in the MAINTAINERS file.
Happy hacking
I am pleased to announce that the GCC Steering Committee has
promoted Vladimir Makarov to Register Allocation Maintainer.
Please join me in congratulating Vlad.
Please update your listing in the MAINTAINERS file.
Happy hacking!
David
On 01/05/2011 09:44 AM, roy rosen wrote:
2011/1/3 Jeff Law:
On 12/27/10 08:43, roy rosen wrote:
I'd recommend to try ira-improv branch. I think that part of the problem
is
in usage of cover classes. The branch removes the cover classes and
permits
IRA to use intersected register classes and t
On 01/03/2011 10:41 AM, Jeff Law wrote:
On 12/27/10 08:43, roy rosen wrote:
I'd recommend to try ira-improv branch. I think that part of the
problem is
in usage of cover classes. The branch removes the cover classes and
permits
IRA to use intersected register classes and that helps to assig
Why not simply put in the interference graph edges for all registers
which are not possible for a pseudo and let the coloring algorithm
select the best hard reg.
That's largely what the ira-improv branch does. Register classes at that
point are used primarily to drive the costing model.
Actuall
2011/1/3 Jeff Law :
> On 12/27/10 08:43, roy rosen wrote:
>>>
>>> I'd recommend to try ira-improv branch. I think that part of the problem
>>> is
>>> in usage of cover classes. The branch removes the cover classes and
>>> permits
>>> IRA to use intersected register classes and that helps to assig
On 12/27/10 08:43, roy rosen wrote:
I'd recommend to try ira-improv branch. I think that part of the problem is
in usage of cover classes. The branch removes the cover classes and permits
IRA to use intersected register classes and that helps to assign better hard
registers.
I tried now thi
2010/12/23 Vladimir Makarov :
> On 12/23/2010 03:13 AM, roy rosen wrote:
>>
>> Hi All,
>>
>> I am looking at the code generated by my port and it seems that I have
>> a problem that too many copies between registers are generated.
>> I looked a bit at the r
On 12/23/10 09:50, Vladimir Makarov wrote:
Defining classes for pseudos is already one of the most expensive
operation in IRA. Looking at the flow would make it even more
complicated (I even don't know how to use this to improve the
allocation because it means live range splitting before col
On 12/23/2010 03:13 AM, roy rosen wrote:
Hi All,
I am looking at the code generated by my port and it seems that I have
a problem that too many copies between registers are generated.
I looked a bit at the register allocation and wanted to verify that I
understand its behavior.
Is that true
Hi All,
I am looking at the code generated by my port and it seems that I have
a problem that too many copies between registers are generated.
I looked a bit at the register allocation and wanted to verify that I
understand its behavior.
Is that true that it first chooses a register class for
BLUE 3TOO writes:
> Ian, thanks a lot for the help. Is there any document
> about IRA (e.g. how the SIMD registers of a
> specific architecture is exposed to the allocation
> process)? or the only option is the read the code?
Vlad described IRA in a paper published in the 2007 GCC Summit
proc
.
> From: i...@google.com
> To: blue_3...@hotmail.com
> CC: gcc@gcc.gnu.org
> Subject: Re: vector register allocation
> Date: Fri, 25 Jun 2010 14:38:19 -0700
>
> BLUE 3TOO writes:
>
>> Can anybody explain how the register allocation is
BLUE 3TOO writes:
> Can anybody explain how the register allocation is handled in GCC?
> Is it done together with the general register allocation? or GCC
> has a separate phase to handle them separately?
There is no separate vector register allocator. All classes of
regi
Hello,
Can anybody explain how the register allocation is handled in GCC? Is it
done together with the general register allocation? or GCC has a separate phase
to handle them separately?
Any pointer to the source code that I can take a look? Thanks
Peng
Bernd Schmidt wrote:
> On 06/15/2010 12:06 AM, Ian Lance Taylor wrote:
> > Well, as you know, subregs have two meanings which look similar but
> > are in fact entirely different. It's valid to set subregs of the same
> > pseudo in parallel if the subregs represent different hard registers.
> > It'
1 - 100 of 187 matches
Mail list logo
