[Webkit-unassigned] [Bug 24986] ARM JIT port

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=24986





------- Comment #37 from barraclough at apple.com  2009-06-17 00:28 PDT -------
Zoltan,

There are three reasons that currently envisage we may require a constant pool
on other platforms:

(1) For immediate values that cannot be represented within instruction
operands.  For example, floating-point and vector values on x86 (& x86-64,
ARMv7).
(2) For values that can be (and currently are being) encoded in the instruction
stream, but that might be more efficient if accessed via a constant pool.  E.g.
on x86-64 it *might* be more efficient to place some pointer immediates in a
constant pool (these are currently loaded via second move immediate
instruction), and on arm-v7 32-bit immediate values are loaded with a 2
instruction sequence, again in some cases it may make sense to switch this to a
data load.
(3) Moving values that are patched out of the instruction stream will remove
the need to i-cache flush on modification, and by organizing constant-pool into
page sized units we may be able to avoid changing protections when running with
NX support.  This may be useful at some point in the future.

> 3.- CP should live in MacroAssembler{ARCH}
> IMHO, there is no need to know anything about CP in this abstraction level.

This way.  This is exactly the kind of thing that the macro assembler is
intended to abstract. :-)  The idea of the assembler classes is that they very
simply provide an interface to encode the machine instructions that are
available on the target processor.  We do not want to intermingle the
instruction formatting mechanism with an instruction selection policy – the
latter should be layered upon the former.  The assembler is, of course, in many
ways on its own a little unhelpful, due to the limitations of the instruction
set - be it the inability to load an arbitrary 32-bit immediate value on ARM,
or the inability to shift by any register on x86, etc, etc.  The MacroAssembler
wraps the architecture specific assembler in a common higher level interface,
providing the facilities as necessary to support its full API, and providing a
richer programming interface.  It is already the case the the MacroAssembler
must handle situations in which an immediate operand to an instruction may not
fit within the range of values supported on a given platform, and in these
situations it will load the value into a register.  Currently it's only option
for doing so is to use immediate moves, but having the option of utilizing a
constant pool also available here would be entirely complementary to existing
mechanisms.

The parts of the implementation that can be shared across platforms (such as
data-structures mapping the constant pool loads to immediate values to be added
to the constant pool) may well fit nicely into the AbstractMacroAssembler layer
to make them available across platforms.

> In
> order to be able to decide when to flush, the MacroAssembler have to be tightly
> coupled with AssemblerBuffer as well.

I'm not sure I would use the term tightly-coupled.  The AbstractMacroAssembler
already has a size() method to check how much has currently been written to the
buffer, it should just be able to use this to check how much code has been
planted since a previous point.  Adding additional calls to check used space
will not be a problem if necessary.

> This case is inconceivable, because the
> MacroAssembler does not know anything about how many bytes are written to the
> buffer when a function of the Assembler is called.

Sure it does!  There should be a one-to-one mapping between calls to the
Assembler and instructions planted, and as such the assembler can assume that
the number of bytes written by an assembler call will be whatever the maximum
instruction width is for that platform (4, in the case of ARM).


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.