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


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]