On Tue, Nov 29, 2016 at 11:32:41AM +0000, Kyrill Tkachov wrote:
<snip>
> >>+
> >>+/* Implement TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB. */
> >>+
> >>+static sbitmap
> >>+aarch64_components_for_bb (basic_block bb)
> >>+{
> >>+ bitmap in = DF_LIVE_IN (bb);
> >>+ bitmap gen = &DF_LIVE_BB_INFO (bb)->gen;
> >>+ bitmap kill = &DF_LIVE_BB_INFO (bb)->kill;
> >>+
> >>+ sbitmap components = sbitmap_alloc (V31_REGNUM + 1);
> >>+ bitmap_clear (components);
> >>+
> >>+ /* GPRs are used in a bb if they are in the IN, GEN, or KILL sets. */
> >>+ for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++)
> >>The use of R0_REGNUM and V31_REGNUM scare me a little bit, as we're
> >>hardcoding
> >>where the end of the register file is (does this, for example, fall apart
> >>with the SVE work that was recently posted). Something like a
> >>LAST_HARDREG_NUM might work?
> >>
> >
> >I think you mean FIRST_PSEUDO_REGISTER. AFAICS the compiler uses
> >a loop from 0 to FIRST_PSEUDO_REGISTER to go through the hard registers
> >in various places in the midend.
> >I'll change it to use that, though if the way to save/restore such new
> >registers becomes
> >different from the current approach (i.e. perform a DI/DFmode memory op) the
> >code in these
> >hooks will have to be updated anyway to take it into account.
> >
>
> And actually trying to implement this blows up. The "hard" registers include
> CC_REGNUM, which we definitely want to avoid 'saving/restoring'. We really
> just want to save the normal register data registers, so is it okay if I
> leave it as it is? The prologue/epilogue code already uses V31_REGNUM, so it
> would need to change anyway if new registers are added in the future.
Well, you could always define a new constant in aarch64.md ?
(LAST_SAVED_REGISTER 63)
Which would still save hardcoding V31_REGNUM everywhere.
And yes, the pro-/epilogue functions could also do with this fix
(preapproved).
James
