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

[bugzilla-daemon at webkit.org]

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





------- Comment #38 from zherczeg at inf.u-szeged.hu  2009-06-17 02:13 PDT -------
On ARM, every immediate values are limited. Constant values are 8 bit values
shifted by an even number, memory adresses must be at maximum 4095 bytes away
from a base register, the relative offset of branches are limited to +-32
Mbytes and so on. We do not store addresses in the constant pool by
convenience, we do this because there is no other (reasonable) way. An
independent constant pool which is not embedded into the code is limited to 8
kbytes because of the addressing limitations. Even if they are independent, we
still need a way to load their base offset into a register, and we need to
prepare multiple constant pools. External constant pools require too much
efforts, and this is not the ARM way. ARM constants pools are embedded into the
code, and protected by a branch instruction from execution.

What we store in the constant pool
 - immediates, if they cannot be encoded as at most two instructions
 - branch/call targets, since we don't know the target is within +-32Mbytes in
advance. Although it might be unusual to generate bigger JIT code than 32
MBytes, it would be a security hole to do it any other way.
 - addresses which will be patched later. Same reason as before: we don't know
the immediate will fit into data processing instructions.

If we want to know the size of an instruction in advance, we must always
generate the worst case scenario. I.e: let's assume there is a macro assembler
instruction which can be encoded as 1 (90%), 2 (7%) or 3(3%) instructions. If
we insist to keep the code size fixed, we have to generate 3 instructions all
the time, because of that 3%. From this viewpoint, x86 CISC looks more
fixed-size than ARM.

>From assembler viewpoint we have 3 kinds of instruction:
  - normal instruction
  - instruction with constant (if the constant is already in the pool, we can
reuse its address)
  - instruction with unique constant (branches and other values patched later)

Something has to maintain state of the constant pool, and push it when
necessary.
  - It can be done on MacroAssembler level, but in that case MacroAssembler
must know which type of instruction (see above) is given.
  - It can be done on formatter level, in that case macro assembler knows
nothing about the constant pool.

I doubt it is possible to maintain the constant pool without information about
the instruction types.

I know the current assembler model is not prepared for variable length
instructions, but it is essential on RISC architectures, where the generated
code size depend on both the arguments and the current environment (state of
the constant pool). On ARM, even a simple "mov(reg, reg)" may take 4 from
4096+4 bytes. The only barrier I saw to support variable length instruction is
those patchOffsets used by property accesses. Are they really that important?
Can we have a define to enable variable length instructions and put extra
labels during code generation? In this case we could keep the advantages of
both approach.

Besides, Gabor wrote the post you answered :)


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