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>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 7 Apr 2014 08:06:37 +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>
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
> >> of these registers, but I imagine that's true either way.
> > Perhaps. I am currently thinking/hoping that simply having them
> > 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
> > 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
> > 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
> > 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.