|
From: lin z. <man...@gm...> - 2015-05-25 10:39:24
|
Hi,
I am planning to improve the performance of VEX. And I think of
WebKit JavaScriptCore has been trying to use LLVM as its new backend
for a year. Today I try to run the trunk version in V8 benchmark set, and
the result is impressive:
Richards: 27228
DeltaBlue: 32054
Crypto: 27626
RayTrace: 54241
EarleyBoyer: 42266
RegExp: 3225
Splay: 20413
NavierStokes: 27992
----
Score (version 7): 23768
whereas v8 4.4.48
Richards: 31232
DeltaBlue: 46177
Crypto: 25157
RayTrace: 68079
EarleyBoyer: 40312
RegExp: 5466
Splay: 20071
NavierStokes: 29414
----
Score (version 7): 27439
Please note that V8 has a extremely powerful runtime, like semi-space
gc. And its primitive encoding is much more compact, easier to
optimize. So this result may mean the compilation part of JSC has
won.
So I dig into what Apple has done to LLVM. One of the most important
modification I think is enabling runtime patching for the code generated
by LLVM, by adding the notion stack map.
Stack map is data section named "llvm_stackmaps". It records the
patch information, like where to do the patching.
The patch point may be shadowed by two intrinsic functions:
llvm.experimental.stackmap
llvm.experimental.patchpoint
The difference is the latter one enabling calling convention for
patching, and defining what is defined and what is used using return
value and parameters respectively.
Another important modification is enable the developers to manage the
code/data memory region themselves. That is what
CreateSimpleMCJITMemoryManager
API does.
I am planning to write a new backend parallel to host_x86,
host_arm..., after the IR statements optimizations.
That should be beneficial, especially the instructions with
prediction, like "addeq r0, r0, r1", which is translated to:
add r2 = r0 + r1
r3 = ite(eq, r2, r0)
in LLVM IR, that will change to something with basic block,
hopefully becomes:
if (cc & Z) {
r2 = r0 + r1
}
r3 = phi(r2, r0)
--
Lin Zuojian
|