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

[bugzilla-daemon at webkit.org]

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





------- Comment #7 from loki at inf.u-szeged.hu  2009-04-03 05:38 PDT -------
It would be good for us as well if the MacroAssembler were the only module
which had to be rewritten, but unfortunately that is not the case here.

We have some barriers which have to be solved to generate machine code on ARM:

1. Constant pool:
On ARM, only those constants can be fit into an instruction which can be
produced from a 8 bits long number rotated twice by a 4 bit unsigned integer.
For example 257 (0x101) does not fit. This implies that the constant pool is
needed. There are two possible solutions. (1) Leave the constant on CallFrame,
or (2) insert them into the machine code. The first solution is not
satisfactory, because on ARM the space is limited (12 bit) to represent an
offset from the base. If the offset does not fit, more instructions are needed
to access the address. In the second solution, we have to put extra code which
jumps through the constant pool. This case is still better than the first one,
because it generates much less machine code. Additionally we have to generate
other constants as well, like addresses of stub and CTI functions, far jumps,
etc. So, those extra constants have to be stored in the constant pool too (not
on CallFrame).

2. Branch optimization:
There is an option to use faster and more predictable branches. Initially, we
generate all branches with PC relative load which uses one constant address and
one machine instruction. After the JIT code generation is finished, we can
replace the PC relative load with a simple branch instruction if the address
fits in the instruction. This replace saves space and times as well. All the
above implies that the compilation should have a second phase to do the
replacing.

3. Exception handling:
On ARM, we cannot follow the strategy of the exception handling used on x86. We
cannot regenerate identical instructions sequences when an exception happens,
because relative calls and constants in the pool are not necessarily the same
(as described above, see items 1 and 2). The return address manipulation is
solved through stub functions.

4. Conditional field:
All ARM instructions are conditionally executed. So, we can avoid short jumps
(cmp and jmp combo). See a really small example at 'op_construct_verify'. On
ARM, we can combine the two jumps using the conditional field.

5. Dynamically generated stub functions:
We eliminated all inline assembly codes from the source code and replaced them
with dynamically generated JIT codes. We generate the following code snipets
dynamically: ABI switch (trampoline in your terminology), return address
manipulation for exception handling, and soft math instructions. The most
interesting part is the stub functions for return address manipulation. Because
of exception handling, we cannot address some CTI functions directly. For those
functions, stub functions are generated where we can solve the return address
manipulation.

6. Bigger patterns worsen performance:
At last, if we generate machine code through MacroAssembler we will miss more
target specific optimizations. Using a general function of MacroAssembler to
generate an operation can often generate useless code. This is similar issue
like at super-instructions.

I would be the happiest person if we could use MacroAssembler as you said, but
I think it is hard task (and it would lead to performance degradation on ARM).
Additionally, if we would request an interface change necessary for ARM that
would cause performance regression on x86, it would be rejected. :-) However, I
am open to make our points of view converge. The truth must lie somewhere
inbetween our approaches.

Feel free to comment or ask!

Regards,
Gabor


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