Bug 122746 – [sh4] Introduce const pools in LLINT

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Julien Brianceau]

In current implementation of LLINT for sh4, immediate values outside range -128..127 are loaded this way:

            mov.l .label, rx
            bra out
            nop
            .balign 4
            .label: .long immvalue
            out:

These immediate values could be grouped in constant pools placed behind non-return opcodes to avoid useless branches and reduce code size.

[Julien Brianceau]

Created attachment 214139 [details]
Introduce const pools in sh4 LLINT

generated LowLevelInterpreter.o size is 32848 bytes with this patch instead of 33928 bytes without (-3.2%).

[Julien Brianceau]

Created attachment 214140 [details]
generated LLIntAssembly.h on r157387 without patch

[Julien Brianceau]

Created attachment 214141 [details]
generated LLIntAssembly.h on r157387 with patch

[Julien Brianceau]

Ooops, sorry for the size of the patches.. a zip would have been more appropriate.
If there's a way to delete attachments, feel free to delete the 2 generated LLIntAssembly.h, I'll upload a zip file then.

[kov's GTK+ EWS bot]

Comment on attachment 214139 [details]
Introduce const pools in sh4 LLINT

Attachment 214139 [details] did not pass gtk-wk2-ews (gtk-wk2):
Output: http://webkit-queues.appspot.com/results/4004005

[Julien Brianceau]

The ConstPoolEntry class describes a constant: a size (16 or 32 bits), a value, a label (instance of LocalLabel) and a reference on it (instance of LocalLabelReference).
The ConstPool class describes a contant pool: a set of entries (ConstPoolEntry instances) of a specific size (16 or 32 bits).

The sh4LowerConstPool function iterates on all opcodes and handles two constant pools: one for 16 bit constants (currentPool16) and one for 32 bit constants (currentPool32):
- these 2 pools will be filled with constants when needed (case of the "move" opcode with values outside -127..128 range)
- these 2 pools will be flushed (if non empty) after non return opcodes "jmp" and "ret"
- before adding an entry in the pool, we check that there isn't already an entry with the matching value in it (in this case we reuse it instead of creating a new one)
- 16 bit entries are put before 32 bit ones because the max offset between the move opcode and the constant is 512 bytes for 16 bit values, whereas it's 1024 bytes for 32 bit ones
- there is 2 separate pools to avoid space wasted by alignment constraints

[WebKit Commit Bot]

Comment on attachment 214139 [details]
Introduce const pools in sh4 LLINT

Clearing flags on attachment: 214139

Committed r157452: <http://trac.webkit.org/changeset/157452>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.