makeAddress and large frame sizes

[Christian Wimmer]

On 04/29/2014 09:39 AM, Doug Simon wrote:
> How does C1 and C2 on SPARC handle this?

Very "elegantly" with a bailout.
This is the code from the C1 register allocator:

int LinearScan::allocate_spill_slot(bool double_word) {

   ...

   // the class OopMapValue uses only 11 bits for storing the name of the
   // oop location. So a stack slot bigger than 2^11 leads to an overflow
   // that is not reported in product builds. Prevent this by checking the
   // spill slot here (altough this value and the later used location name
   // are slightly different)
   if (result > 2000) {
     bailout("too many stack slots used");
   }

   return result;
}



>
> On Apr 29, 2014, at 4:49 PM, D.Sturm <D.Sturm42 at gmail.com> wrote:
>
>> Hi,
>> This is a bit complicated, but I hope I can make the problem
>> comprehensible.
>>
>> The Aarch64 ISA only allows a 9-bit signed unscaled offset added to a
>> register for memory accesses. Consequently for stacks that are larger than
>> 2^8 byte we have a problem when using AbstractAssembler.makeAddress to
>> access something on the stack with an offset larger than 256 bytes. (SPARC
>> seems to have the same problem and seems to just ignore the problem -
>> 13-bit signed offsets work fine for all JTT tests I guess)
>>
>> I can solve that problem when loading values from the stack since I can use
>> the result register as a scratch register (and don't
>> use CompilationResultBuilder.asAddress but compute the stack offset myself).
>>
>> But when storing values *into* the stack I really need to allocate a
>> temporary register if the offset is too large. Always allocating a scratch
>> register even if I only need it in case of a large stack and worse even for
>> reg->reg moves since I don't know whether the register allocator will
>> actually use a register for the destination and not a stackslot when
>> generating LIR instructions seems like a really unfortunate solution.
>>
>> I was thinking I could specify a scratch register for all moves and then
>> in beforeRegisterAllocation() remove the load if I can guarantee that the
>> stack won't be too large (hard since I don't know how many registers the
>> register allocator will have to spill? some heuristic seems necessary).
>>
>> Sounds reasonable or any problems with that approach? Or maybe some
>> completely different solution?
>>
>>
>> --Daniel
>