632738 - Investigate the possibility of removing literal pools on ARM.

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Jacob Bramley [:jbramley]]

If the ARM back-end does not use literal pools, we don't need to
protect code regions in the ICs. This protection surely imposes a
performance penalty (though I don't know quite to what degree), and it
is a safety risk because it is too easy to forget to protect a relevant
region. This has been the cause of a few bugs recently.

The back-ends are currently configured as follows:

                        ARM ("MacroAssemblerARM")           Thumb-2 ("MacroAssemblerARMv7")
One-shot literals       In-line, or literal pool.           In-line.
Patchable literals      Literal pool.                       In-line.

The Thumb-2 back-end has not been integrated into Jaeger Monkey.
However, it already supports literal-pool-less operation.

Szeged University have investigated this problem in the context of
WebKit, and found that the current configuration is the most optimal.
(By that, I mean that Thumb-2 seems to work best with in-line literals,
but ARM works best with the hybrid approach.)

Currently, with ARM code, literal pools are used for any literal that
needs to be patched. This includes all branches, due to bug 586297. In
addition, if MOVW and MOVT are not available, large literal immediates
will also be encoded in literal pools.

Removing the dependency on literal pools altogether is not practical for
ARMv6 and older. However, those platforms are not our priority. It
would, I think, be reasonable to disable ICs on ARMv6 and optimize for
the ARMv7 case.

I think the best way to proceed would be to integrate the Thumb-2
back-end as the ARMv7 option, so ARMv7 builds always use the Thumb-2
back-end. This leaves the ARM back-end for the ARMv6 build. Another
option is to remove literal pools from the ARM back-end, but that might
get complicated and it isn't likely to work well on ARMv6.

Integrating the Thumb-2 back-end essentially requires adding another
target architecture to Jaeger Monkey, but it won't be nearly as
complicated as adding the ARM back-end because most of the work is
already done, and it behaves quite similarly to ARM.

Comment 1

[Nicholas Nethercote [inactive]]

I found in bug 631106 that the literal pools greatly complicate the allocation of executable memory in JM.  Eg. see the two versions of ARMAssembler::executableCopy(), which in turn complicate various other things.

So if their use could be removed I'd be very happy!

Comment 2

[Jacob Bramley [:jbramley]]

I don't think this is relevant any more, since things work quite differently now. Also, we would still need to maintain the ARM back-end (and support its literal pools) for ARMv6 targets.