On 01.10.2019. 21:35, Jeff Law wrote: > On 9/6/19 4:23 AM, Dragan Mladjenovic wrote: >> On 24.07.2019. 20:57, Jeff Law wrote: >>> On 7/17/19 2:29 AM, Dragan Mladjenovic wrote: >>>> >>>> >>>> On 09.07.2019. 23:21, Jeff Law wrote: >>>>> On 7/9/19 2:06 PM, Dragan Mladjenovic wrote: >>>>>> This patch prevents merging of CALL instructions that that have different >>>>>> REG_CALL_DECL notes attached to them. >>>>>> >>>>>> On most architectures this is not an important distinction. Usually >>>>>> instruction patterns >>>>>> for calls to different functions reference different SYMBOL_REF-s, so >>>>>> they won't match. >>>>>> On MIPS PIC calls get split into an got_load/*call_internal pair where >>>>>> the latter represents >>>>>> indirect register call w/o SYMBOL_REF attached (until machine_reorg >>>>>> pass). The bugzilla issue >>>>>> had such two internal_call-s merged despite the fact that they had >>>>>> different register usage >>>>>> information assigned by ipa-ra. >>>>>> >>>>>> As per comment form Richard Sandiford, this version compares reg usage >>>>>> for both call >>>>>> instruction instead of shallow comparing the notes. Tests updated >>>>>> accordingly. >>>>>> >>>>>> gcc/ChangeLog: >>>>>> >>>>>> 2019-07-09 Dragan Mladjenovic <dmladjeno...@wavecomp.com> >>>>>> >>>>>> * cfgcleanup.c (old_insns_match_p): Check if used hard regs set is equal >>>>>> for both call instructions. >>>>>> >>>>>> gcc/testsuite/ChangeLog: >>>>>> >>>>>> 2019-07-09 Dragan Mladjenovic <dmladjeno...@wavecomp.com> >>>>>> >>>>>> * gcc.target/mips/cfgcleanup-jalr1.c: New test. >>>>>> * gcc.target/mips/cfgcleanup-jalr2.c: New test. >>>>>> * gcc.target/mips/cfgcleanup-jalr3.c: New test. >>>>> THanks. I've installed this on the trunk. >>>>> >>>>> jeff >>>> Thanks. Can this be back-ported to active branches also. This issue >>>> seems to be there > since gcc6 if not gcc5. >>> I've asked Matthew to handle the backport. I'm going to be on PTO the >>> next couple weeks. >>> >>> jeff >>> >> >> Hi, >> >> Sorry, I forgot to check up on this patch. Is it still ok for me to try >> to backport it to gcc 9 and gcc 8 branches? > Yes, this would be fine to backport to gcc-8 and gcc-9 branches. I'd > expect it to be pretty easy as I don't think old_insns_match_p has > changed much.
Thanks and sorry for the delay. Backported as r277625 and r277626 to gcc-9 and gcc-8 branch respectively. Best regards, Dragan
