This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [Patch MIPS] Enable TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS hook
- From: Robert Suchanek <Robert dot Suchanek at imgtec dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, "Catherine_Moore at mentor dot com" <Catherine_Moore at mentor dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 15 Jun 2015 14:41:33 +0000
- Subject: RE: [Patch MIPS] Enable TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS hook
- Authentication-results: sourceware.org; auth=none
- References: <B5E67142681B53468FAF6B7C3135656244159813 at hhmail02 dot hh dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B0235321062CEC at LEMAIL01 dot le dot imgtec dot org> <B5E67142681B53468FAF6B7C3135656244159C00 at hhmail02 dot hh dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B02353210667BF at LEMAIL01 dot le dot imgtec dot org>
Hi Matthew,
> /* LRA will allocate an FPR for an integer mode pseudo instead of spilling
> to memory if an FPR is present in the allocno class. It is rare that
> we actually need to place an integer mode value in an FPR so where
> possible limit the allocation to GR_REGS. This will slightly pessimize
> code that involves integer to/from float conversions as these will have
> to reload into FPRs in LRA. Such reloads are sometimes eliminated and
> sometimes only partially eliminated. We choose to take this penalty
> in order to eliminate usage of FPRs in code that does not use floating
> point data.
>
> This change has a similar effect to increasing the cost of FPR->GPR
> register moves for integer modes so that they are higher than the cost
> of memory but changing the allocno class is more reliable.
>
> This is also similar to forbidding integer mode values in FPRs entirely
> but this would lead to an inconsistency in the integer to/from float
> instructions that say integer mode values must be placed in FPRs. */
>
> I'm keen to get the description of this right so please feel free to change
> it further if it isn't clear (or correct).
This description is definitely more accurate. At first glance, I wasn't sure
whether to include the bit about partial elimination since it caused by post
reload passes but the introduction of reloads should be avoided in the first place.
> I don't know if this change will lead to classic reload being unusable for
> MIPS. I'm not worried about that but I think it is probably wise to
> remove classic reload support for MIPS now; we are dependent on LRA for
> several features already.
Indeed. I think it's the right time to drop the classic reload and resolve
LRA issues if they come up.
> Do you have any details on when we are left with suboptimal code for
> int->float conversions? I'd like to keep a record of them in this thread
> or in the comment so we know what is left to fix.
I opened a bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66204
and just realised that I had never CCed Vlad. Hopefully, this is the last
remaining issue related to integers and floating-point registers.
>
> > + if (INTEGRAL_MODE_P (PSEUDO_REGNO_MODE (regno)) && allocno_class ==
> > ALL_REGS)
> > + return GR_REGS;
> > + return allocno_class;
> > +}
> > +
>
> Trim the extra trailing newline.
>
> OK to commit if you are happy with the comment.
I'll update the comment, do a quick regression and commit it.
Regards,
Robert