This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: try_merge_delay_insn with delay list > 1


Great, I'll read more closely formatting rules next time I'll submit something.

Regards,

Selim


-----Message d'origine-----
De : Jeff Law [mailto:law@redhat.com] 
Envoyé : lundi 20 avril 2015 19:47
À : BELBACHIR Selim; gcc@gcc.gnu.org
Objet : Re: try_merge_delay_insn with delay list > 1

On 04/20/2015 05:08 AM, BELBACHIR Selim wrote:
> I've attached the fixed version of the patch. I've tested it on the trunk with my private target.
>
> I can't provide a test because apparently no backend (other than my private one) uses delay slots with more that 1 slot.
> I was also unable to test the behaviour of this patch for an hypothetic target providing delay lots with more that 1 slot AND the possibility to annul instruction in delay slots.
>
> It seems to me that this patch is a small enhancement anyway.
> I hope it's ok for trunk :)
Even for small enhancements or bugfixes, we try to at least do some basic testing.  Unfortunately with no sparc or mips machines in the compile farm, good testing of a reorg.c change is hard.

I built mips-elf cross tools and used those to compile newlib for mips-elf.  Then I applied your patch, rebuilt the compiler and used that to compile newlib again.  Then I compared all the objects from the two copies of newlib and verified the code we generated as identical.  So there's at least some degree of confidence we didn't mess anything up in the single delay slot case.

I fixed a couple more minor formatting problems and installed your change on the trunk.

jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]