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

[bugzilla-daemon at webkit.org]

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





------- Comment #24 from zherczeg at inf.u-szeged.hu  2009-06-11 11:15 PDT -------
Hi!

> (From update of attachment 31155 [review])
> I'm not sure why you have made the changes to AssemblerBuffer.h -- they're not
> needed for the v7 assembler.  I think those changes make the patch larger than
> they need to be which masks the actual meaningful changes.

The answer is: Constant pool. Since ARM is a RISC CPU, immediates are limited
to rotated 8 bit values. Generating 4 instructions for each load immediate
values is a waste of memory space and slower than a pc relative load. I fear
you will also need a constant pool later if you would like to extend the 16M
limit of your ARMv7. You can read more about it here:
http://webkit.sed.hu/node/17

> The changes to codeblock seems worrisome as well -- exception information is
> very large (in the order of megs per page) which is why we create the
> information lazily -- while i realise you are making unique constants in the
> codestream is it not possible to generate the same *sized* instructions? 

We always keep the m_callReturnIndexVector after the code is generated, its
size is not that big. Otherwise, we didn't modify the lazy exception
information generation.

> Regenerating the code to create exception information merely requires the
> offsets be the same, not that the code be absolutely identical.  If you can
> make such a guarantee then you should be able to reduce memory usage, and
> further reduce the number of changes needed to non-arm code (in general we are
> trying to move to less ifdefs rather than more).

Load immediates (pointers) always cause trouble. Depending on where they are in
the memory, the generated code looks different. And I am totally agree about
ifdefs.

> I'm not really happy with the changes to JITPropertyAccess as neither x86,
> x86-64, nor ARMv7 required these changes, why do we need them in <v7 ARM?

Constant pools again. We must ensure that a constant pool will not break the
instruction list. Otherwise the hard coded offsets become useless.
Alternatively, we could kill those constants and put labels everywhere when an
offset needs to be stored. The extra memory cost is minimal, and the whole
thing looks much portable.

> I'm not entirely sure what Tape is -- it looks like a less generic, but
> iterable version of SegmentedVector, is this a correct assessment?  Can you not
> just make SegmentedVector be iterable?

Why SegmentedVector is not in the /wtf directory if it is intended for generic
use? Perhaps the advantages of the two can be merged together. You could also
replace several Vectors with Tape. It is faster since it doesn't need to
reallocate the segments all the time.

> I'm going to hold off r- for now (pending your response to these questions) but
> i'll need gavin to review the assembler proper

I hope I could answer for your questions. This is actually the fastest version
we could squeeze from macro assembler.


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