makeAddress and large frame sizes

[Thomas Wuerthinger]

Yes. 2^14 number of stack slots ought to be enough for everybody. - thomas

On 29 Apr 2014, at 19:36, D.Sturm <D.Sturm42 at gmail.com> wrote:

> I'll just pass the transferSize around to the memory accesses then. Since StackSlots are aligned and always at positive offsets to the SP I can use a different addressing mode to get a 14-bit range. 
> 
> That should take care of this problem for all practical purposes I guess.
> 
> --Daniel
> 
> 
> On 29 April 2014 19:30, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> 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
>>> 
> 
>