On 02/14/2013 03:28 AM, Vladimir Makarov wrote:
On 13-02-13 6:36 PM, Michael Eager wrote:
[snip]
I thought about register pressure causing this, but I think that
should cause
spilling of one of the registers which were not used in this long
sequence,
rather than causing a large number of
On 02/14/2013 03:46 AM, Michael Veksler wrote:
On 02/14/2013 03:28 AM, Vladimir Makarov wrote:
On 13-02-13 6:36 PM, Michael Eager wrote:
[snip]
I thought about register pressure causing this, but I think that
should cause
spilling of one of the registers which were not used in this long
On 02/14/2013 06:31 PM, Vladimir Makarov wrote:
On 02/14/2013 03:46 AM, Michael Veksler wrote:
[snip]
I am reading this thread and getting more and more puzzled. The RA
stuff is very complicated,
having many constraints and many dependencies with other passes.
Taking this into
account, it
On 02/14/2013 02:41 PM, Michael Veksler wrote:
...
It sounds that your model requires many 0,1 variables. If it is so,
then maybe SAT
is a better choice than ILP.
Yes, it is binary ILP.
I don't see any progress, ILP solver may be ten times faster but they
still have exponential
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 comparison
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 long
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 using -O3.
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 (and gcc-head) compared with older (gcc-4.1.2).
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 (and
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.
if
Matt Lee writes:
Matt The problem is, that though the loads can be optimized by pipelining
Matt them. The register allocator has created a dependency by using only r3
Matt and r4, instead of using the other volatiles.
GCC's register allocator currently is designed to minimize the
number
On 05 September 2007 23:47, Matt Lee wrote:
Registers r3 to r12 are volatiles. However, for the C code below,
struct foo {
int a[4];
} ;
struct foo p, q;
void func ()
{
memcpy (p, q, sizeof (struct foo));
}
I am getting a instruction sequence for func() such as,
load
On 9/6/07, David Edelsohn [EMAIL PROTECTED] wrote:
Matt Lee writes:
Matt The problem is, that though the loads can be optimized by pipelining
Matt them. The register allocator has created a dependency by using only r3
Matt and r4, instead of using the other volatiles.
GCC's
On 9/6/07, Dave Korn [EMAIL PROTECTED] wrote:
On 05 September 2007 23:47, Matt Lee wrote:
Registers r3 to r12 are volatiles. However, for the C code below,
struct foo {
int a[4];
} ;
struct foo p, q;
void func ()
{
memcpy (p, q, sizeof (struct foo));
}
I am
Matt Lee writes:
Date: Thu, 06 Sep 2007 15:02:52 -0400
From: David Edelsohn [EMAIL PROTECTED]
Matt There is no point trying to minimize usage of volatile hard registers,
Matt is there? They are precisely there to be used up as much as needed.
Matt The function is a leaf procedure as well, so
load r3, q + 0
load r4, q + 4
store r3, p + 0
store r4, p + 4
load r3, q + 4
load r4, q + 8
store r3, p + 4
store r4, p + 8
These last four lines should be
load r3, q + 8
load r4, q + 12
store r3, p + 8
store r4, p + 12
Did you just typo it or do you have a
On 9/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Matt Lee writes:
Date: Thu, 06 Sep 2007 15:02:52 -0400
From: David Edelsohn [EMAIL PROTECTED]
Matt There is no point trying to minimize usage of volatile hard registers,
Matt is there? They are precisely there to be used up as much as
On 9/6/07, Segher Boessenkool [EMAIL PROTECTED] wrote:
load r3, q + 0
load r4, q + 4
store r3, p + 0
store r4, p + 4
load r3, q + 4
load r4, q + 8
store r3, p + 4
store r4, p + 8
These last four lines should be
load r3, q + 8
load r4, q + 12
store r3,
Hello,
On my simple RISC architecture I am seeing suboptimal instruction
scheduling with GCC-4.1.1 caused by the way registers are getting
allocated. I am looking for suggestions on what could be wrong in my
description to cause the poor allocation.
More details --
Registers r3 to r12 are
Matt Lee [EMAIL PROTECTED] writes:
The problem is, that though the loads can be optimized by pipelining
them. The register allocator has created a dependency by using only r3
and r4, instead of using the other volatiles.
Try using -frename-registers.
Ian
20 matches
Mail list logo
