This is the mail archive of the
mailing list for the GCC project.
RE: HARD_REGNO_CALL_PART_CLOBBERED and regs_invalidated_by_call
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>, Jeff Law <law at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 7 Apr 2014 09:30:53 +0000
- Subject: RE: HARD_REGNO_CALL_PART_CLOBBERED and regs_invalidated_by_call
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534D7B3E at LEMAIL01 dot le dot imgtec dot org> <8761moxjhl dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534DB619 at LEMAIL01 dot le dot imgtec dot org> <87vbumw9r8 dot fsf at talisman dot default>
Actually add Jeff this time...
> -----Original Message-----
> From: Matthew Fortune
> Sent: 07 April 2014 09:07
> To: 'Richard Sandiford'
> Cc: firstname.lastname@example.org
> Subject: RE: HARD_REGNO_CALL_PART_CLOBBERED and regs_invalidated_by_call
> Richard Sandiford <email@example.com> writes:
> > Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > > Richard Sandiford <firstname.lastname@example.org> writes:
> > >> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > >> Maybe some RA heuristics will need tweaking to reflect the extra
> > cost
> > >> of these registers, but I imagine that's true either way.
> > >
> > > Perhaps. I am currently thinking/hoping that simply having them
> > marked
> > > as call clobbered will be enough.
> > FWIW, I have some patches queued for stage 1 that tell the target-
> > independent code which registers are saved by the current function.
> > This makes things like interrupt functions less magical.
> > Maybe it would help with exposing the "call-clobbered and call-saved"
> > thing to RA.
> That could be useful if existing costs don't lead to the correct
> registers being targeted first.
> > > In terms of the HARD_REGNO_CALL_PART_CLOBBERED macro. I would say
> > that
> > > it is poorly named as it gives no indication to GCC internals as to
> > > which part of the register is clobbered and which is not.
> > I don't think it was really supposed to matter. (Not that I'm
> > defending the name. :-))
> > > When this macro
> > > returns true GCC simply takes that to mean the whole register is
> > > clobbered. I'd say that then makes my usage legitimate. If I had
> > > time and will power I'd remove the 'PART' from this macro and switch
> > > over to having it as the primary source of call-clobbered
> > > information in GCC doing away with call_used_regs etc. Having the
> > > mode information
> > is
> > > quite valuable as we are seeing with SIMD ISA extensions that use
> > this macro.
> > > Supporting two sources of call-clobbered data is probably what lead
> > us
> > > to the current situation of broken optimisation passes.
> > Definitely agree with the last part. But I think it'd be better to
> > fix it the other way: get rid of the existing
> > HARD_REGNO_CALL_PART_CLOBBERED uses in the generic code and replace
> > things like call_used_regs with mode-indexed HARD_REG_SETs of the
> > call- clobbered registers. You could then add a cleaner target
> > interface that says whether a given register is call-clobbered in a
> given mode.
> > The default could use the existing HARD_REGNO_CALL_PART_CLOBBERED,
> > CALL_USED_REGISTERS and CALL_REALLY_USED_REGISTERS (another horrible
> > part of the interface).
> Indeed and this could potentially capture information on which part of a
> register is clobbered though it is difficult to imagine what to then do
> with such information!
> > Doing it that way wouldn't involve any changes to port-specific code
> > other than MIPS. Other ports could use the default implementation and
> > switch to the new interface later.
> > I realise that might be more work than you were planning on, but if
> > you're having to change existing passes anyway then we might as well
> > fix it in a way that reduces the number of places that need to check
> > two things instead of one.
> I have an urgent need to get all this working so it may simply have to
> Include whatever changes are necessary.
> > All IMO of course. I don't maintain this part of GCC.
> It's not clear who would be best to talk to about this. I've added Jeff
> as he appears to be listed against some mostly relevant areas in the
> maintainers file. If you could point me towards anyone more suitable
> that would be good.