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
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 pseudo
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
-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 hav
-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
> 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 ar
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'
-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
> 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
> 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 hal
-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
-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[]
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 loo
13 matches
Mail list logo
