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

[bugzilla-daemon at webkit.org]

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





------- Comment #34 from loki at inf.u-szeged.hu  2009-06-16 00:44 PDT -------
Gavin, first of all, thanks for your comment. As you can see, we have started
splitting the patch into separate smaller changes. We have added the first
patch here in this bug report. Is it good solution for you to place every patch
here in this bug report? Or should we create separate bug reports for each
changes which blocks this bug entry?

The first - and I think is the most important - design issue is the constant
pool. Correct me if I am wrong, but I feel that you does not catch the meaning
of our constant pool design. At AssemblerBufferARM the constant pool contains
addresses which could be changed during runtime. So practically the constant
pool does not contain only constant values. Its name comes from GCC
terminology. Its behavior looks like more an address pool rather than a
constant pool such as
in RegisterFile.

The usage of constant pool is implicated by the ARM machine code itself. If a
MacroAssembler asks to do something with an Address, the target architecture
will have to place the address in a machine instruction or in a register in
order to be able to work with them. On a generic ARM platform every 32 bits
value can be produced by maximum 4 arithmetic instructions. This solution is
not rewarding in every situation (see more at http://webkit.sed.hu/node/17).
So, sometimes we
have to use a PC relative load in order to access a data. A group of values
which are accessed by PC relative loads is a constant pool (in our view). The
limitation of the constant pool is determined by the addressable distance of a
PC relative load. In practice this means that we are collecting the constants
during instruction appending until the distance of the first constant and its
usage reach the maximum distance. After collecting the constant pool have to be
flushed and separated from executable code. This kind of mechanism is not
necessary for every architecture. I hope it was clear, and sorry if you have
known it already.

We can abstract constant pool if you like, but there a design issue which have
to discussed: where should the constant pool implementation should live.

1.- CP should live within a separate AssemberBuffer.
There will be an AssemblerBuffer without CP feature, and a other one
(AssemblerBufferWithCP) with CP. This solution is very simple. Each
architecture can decide which solution is suitable for them. The problem is
here that the functionality of AssemblerBuffer is repeated in
AssemblerBufferWithCP as well (code duplication, copy&paste code, etc.)

2.- CP should live in {ARCH}Assembler.
Each architecture can implement its own constant pool. I think this is a bad
solution, because there will be many code duplication (more than in case 1.),
and the assembler have to be tightly coupled with AssemblerBuffer.

3.- CP should live in MacroAssembler{ARCH}
IMHO, there is no need to know anything about CP in this abstraction level. In
order to be able to decide when to flush, the MacroAssembler have to be tightly
coupled with AssemblerBuffer as well. 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.

4.- CP should live in a separate file (derived from AssemblerBuffer)
This solution is very similar to the case 1). CP lives in a separate file
(AssemblerBufferWithCP) where the constant pool interface have been
implemented, and this class is derived from AssemblerBuffer. In this case the
pubic interface of AssemblerBufferWithCP calls AssemblerBuffer interface
considering the flushing.

What do you think about them?


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