Hi,
On Sat, 7 Jan 2012, Peter Bergner wrote:
While digging through ira-color.c tracking down an IRA shuffle copy
issue, I noticed we only seem to do real copy coalescing for spilled
pseudos. It seems we rely on coloring to try and assign the same hard
reg to pseudos connected by a copy so
On Mon, 2011-11-07 at 09:27 +0100, Michael Matz wrote:
One source of same valued pseudos are copies, and copy coalescing we (of
course) do implement.
While digging through ira-color.c tracking down an IRA shuffle copy issue,
I noticed we only seem to do real copy coalescing for spilled
Hi,
On Sun, 6 Nov 2011, Jeff Law wrote:
On Fri, 2011-11-04 at 12:25 -0600, Jeff Law wrote:
The only way I can think of to have two pseudos assigned the same
hard reg at the same point in the insn stream is if the two
pseudos are known to have the same value.
Having the same value is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/11 17:37, DJ Delorie wrote:
The only way I can think of to have two pseudos assigned the
same hard reg at the same point in the insn stream is if the two
pseudos are known to have the same value.
Since all we're doing is figuring out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/11 14:23, Peter Bergner wrote:
On Fri, 2011-11-04 at 12:25 -0600, Jeff Law wrote:
The only way I can think of to have two pseudos assigned the same
hard reg at the same point in the insn stream is if the two
pseudos are known to have the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 13:13, DJ Delorie wrote:
But doesn't that imply that a hard register is getting inserted
into the array more than once. While I don't see explicit code
to prevent this, I'm having a hard time seeing how that can
actually happen.
On Fri, 2011-11-04 at 12:25 -0600, Jeff Law wrote:
The only way I can think of to have two pseudos assigned the same hard
reg at the same point in the insn stream is if the two pseudos are
known to have the same value.
Having the same value is the more common way two overlapping pseudos
don't
The only way I can think of to have two pseudos assigned the same
hard reg at the same point in the insn stream is if the two pseudos
are known to have the same value.
Since all we're doing is figuring out which hard regs need to be saved
in pro/epilogue, it could be that the two pseudos are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 10:21, DJ Delorie wrote:
But doesn't that imply that a hard register is getting inserted
into the array more than once. While I don't see explicit code
to prevent this, I'm having a hard time seeing how that can
actually happen.
It
But doesn't that imply that a hard register is getting inserted into
the array more than once. While I don't see explicit code to
prevent this, I'm having a hard time seeing how that can actually
happen.
It made no sense to me, but the array overflowed for my RL78 port, and
less than half
But doesn't that imply that a hard register is getting inserted into
the array more than once. While I don't see explicit code to prevent
this, I'm having a hard time seeing how that can actually happen.
The test case is qsort.c from newlib. I added some runtime checks to
caller-saves and
I found this with the rl78-elf port... can't guarantee it's not the
rl78 port itself, but the code does have two loops that fill the
array.
* caller-save.c (setup_save_areas): Increase call_saved_regs[]
size to avoid writing beyond the end of the array. There are
two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/02/11 21:21, DJ Delorie wrote:
I found this with the rl78-elf port... can't guarantee it's not
the rl78 port itself, but the code does have two loops that fill
the array.
* caller-save.c (setup_save_areas): Increase call_saved_regs[] size
13 matches
Mail list logo
