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: HARD_REGNO_CALL_PART_CLOBBERED and regs_invalidated_by_call


Actually add Jeff this time...

> -----Original Message-----
> From: Matthew Fortune
> Sent: 07 April 2014 09:07
> To: 'Richard Sandiford'
> Cc: gcc@gcc.gnu.org
> Subject: RE: HARD_REGNO_CALL_PART_CLOBBERED and regs_invalidated_by_call
> 
> Richard Sandiford <rdsandiford@googlemail.com> writes:
> > Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > > Richard Sandiford <rdsandiford@googlemail.com> 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.
> 
> Regards,
> Matthew


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