makeAddress and large frame sizes

[Thomas Wuerthinger]

The bailout when exceeding a specific frame slot count can be specified in Graal via RegisterConfig#getMaximumFrameSize [1].

This does not solve the problem of though as we need to support stacks with more than 256 bytes on Aarch64. Can you reuse a scratch register that is already reserved for other operations but not in use for storing to the stack?

- thomas

[1] http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/com.oracle.graal.api.code/javadoc/com/oracle/graal/api/code/RegisterConfig.html#getMaximumFrameSize--

On 29 Apr 2014, at 18:49, Christian Wimmer <christian.wimmer at oracle.com> wrote:

> 
> 
> 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
>>