[v8-dev] ARM: safepoints frame optimization

ARM: optimize push/pop of safe points

BUG=
R=ulan@chromium.org, bmeurer@chromium.org

[Benedikt Meurer, 2014-03-13 10:41:49]

https://codereview.chromium.org/194793002/diff/1/src/arm/assembler-arm.h
File src/arm/assembler-arm.h (right):

https://codereview.chromium.org/194793002/diff/1/src/arm/assembler-arm.h#newc...
src/arm/assembler-arm.h:1451: void set_registers_masks(RegList registers_mask,
Nit: One dedicated setter per property.

[vincent.belliard, 2014-03-13 10:53:36]

https://codereview.chromium.org/194793002/diff/1/src/arm/assembler-arm.h
File src/arm/assembler-arm.h (right):

https://codereview.chromium.org/194793002/diff/1/src/arm/assembler-arm.h#newc...
src/arm/assembler-arm.h:1451: void set_registers_masks(RegList registers_mask,
On 2014/03/13 10:41:49, Benedikt Meurer wrote:
> Nit: One dedicated setter per property.

The aim was to ensure that both masks would always been set at the same time
(and so we never forget to set one). If you prefer two functions, I will change
it.

[Benedikt Meurer, 2014-03-13 11:42:04]

+danno, +titzer

As mentioned offline, I don't think it's the right time to start working on
callee-saved registers. It'll also require careful changes to other subsystems.
So, for me that's NOT LGTM at this point.

[danno-g, 2014-03-13 11:56:03]

This CL also seems to completely overlook the work done for stubs that saves
callee-clobbered doubles. Look for LCodeGen::SaveCallerDoubles,
saves_caller_doubles() and allocated_double_registers(), I think your work to
save doubles largely duplicates what's already being done there.
 
Callee-saved non-tagged registers are also not feasible at all, since generally
the caller can never know if they need to save a register as just bits or
interpret it as an object pointer.

[danno-g, 2014-03-13 11:57:07]

Sorry, I meant:

Callee-saved tagged registers are also not feasible at all, since generally
the caller can never know if they need to save a register as just bits or
interpret it as an object pointer, i.e. the caller always need to assume that
tagged registers get clobbered and has to save them before making calls.

[titzer, 2014-03-13 12:06:47]

On 2014/03/13 11:57:07, danno-g wrote:
> Sorry, I meant:
> 
> Callee-saved tagged registers are also not feasible at all, since generally
> the caller can never know if they need to save a register as just bits or
> interpret it as an object pointer, i.e. the caller always need to assume that
> tagged registers get clobbered and has to save them before making calls.

Worse, if we have a call chain A -> B -> C with A having callee-saved registers,
it may be the case that those values are either stored in B or C's frame (or
worse, in some C function's frame somewhere in the middle whose layout we don't
know). If we were to deoptimize B or C we have to handle any registers they have
saved on behalf of their caller (i.e. A). I think this is a major complication
that is likely to have many special cases and produce a steady stream of
hard-to-find bugs.

In general, the strategy to deal with chokepoints like this is to inline the
fast path, which avoids spilling all the registers, and have a deferred path
that only saves the registers in the caller in the slow case.