On 2015/03/09 13:29:07, jarin wrote:
On 2015/03/08 16:23:16, dougc wrote:
When writing the typer, we specifically wanted to keep it simple even if
that
meant less precise typing. We'd prefer to add complexity only if there is
some
real benefit.
Could you please motivate your change by showing some real world examples?
The bitwise-or operation can be used in array index calculations, and used
in
inputs to other operations, that can be usefully optimized if a narrower
range
can be derived. For example: a[(i & 15) | 128].
Being able to derive that bounds checks are not needed does have a big
benefit.
Here's a real world example showing the benefits of type derivation for
bounds
check elimination using the zlib benchmark.
V8 x64 Odin x64
zlib standard: 39.2 29.1
zlib index masking: 30.2 29.7
V8 ia32 Odin x86
zlib standard: 40.8 43.0
zlib index masking 33.7 37.5
V8 is very competitive when using index masking, just a little slower than
Odin
x64 and faster than Odin x86, but this demands a particular JS code style.
Extending the typer to handle operations typically used in index
calculations
well would give app developers more flexibility and help optimize a wider
variety of code.
I believe there are other uses for type informations, other opportunities to
optimize operations if the input ranges have been derived to be narrower.
I am trying to bring Ion/Odin up to a similar level of type derivation
competence, for example
https://bugzilla.mozilla.org/show_bug.cgi?id=1140932 so
that app developers can depend on a certain level of type derivation
support.
The complexity of this patch, and planned work, is not that great and well
isolated. I am only proposing to derive the type for ranges defined by
simple
sets such as the current linear range, and perhaps with an alignment value,
not
to do symbolic range analysis etc.
Even if good deoptimization and bounds check hoisting support is added to
TurboFan, some applications can naturally use index masking such as a VM
written
in JS that uses pointer tagging.
If you are not interested now then I'll probably create a public V8 branch
to
ensure there is BSD licensed support available for future reference?
https://codereview.chromium.org/986073003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
