makeAddress and large frame sizes

[D.Sturm]

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