firstVariableNumber initialization for LinearScan

[D.Sturm]

Hi,
You're right, I missed that requirement - would've saved me some time
debugging the register allocator. I'll use a dummy register then and assert
that it's not used, should be the easiest solution.

--Daniel


On 24 March 2014 10:18, Doug Simon <doug.simon at oracle.com> wrote:

> Hi Daniel,
>
> On Mar 23, 2014, at 11:08 PM, D.Sturm <D.Sturm42 at gmail.com> wrote:
>
> > The constructor for LinearScan uses "this.firstVariableNumber =
> > registers.length;" to assign the first non-register id it can use.
> >
> > That's a problem if the register numbering does have jumps in it, which
> > happens to be true for the Aarch64 HotSpot runtime.
>
> Doesn’t the com.oracle.graal.api.code.Architecture.registers for Aarch64
> then have to contain dummy entries for the register numbers for which there
> no real registers? It would need to so as to conform with the specification
> of Architecture.getRegisters():
>
>     /**
>      * Gets an array of all available registers on this architecture. The
> index of each register in
>      * this array is equal to its {@linkplain Register#number number}.
>      */
>     public Register[] getRegisters() {
>         return registers.clone();
>     }
>
> This specification is what allows "this.firstVariableNumber =
> registers.length;” to be correct for all architectures. I wouldn’t be
> surprised if this property is assumed in other places as well.
>
> So, you’d either need to use the dummy entries I mention above or use the
> translation table you mention below.
>
> > Could we replace it with something like
> >        int maxRegNumber = -1;
> >        for (Register reg : this.registers) {
> >            maxRegNumber = Math.max(maxRegNumber, reg.number);
> >        }
> >        this.firstVariableNumber = maxRegNumber + 1;
> >
> > Otherwise I'd have to introduce a sequential numbering system for Graal
> and
> > translate register numbers when transitioning from Graal to HotSpot.
>
> -Doug
>