On 2014/06/13 10:08:49, Alexandre Rames wrote:
> We tried to go down this route before, but by simplifying all object
accesses
> into a either two loads or a load and a store. That had the
disadvantage of
> reducing the accuracy of GVN and load/store elimination.
>
> This approach doesn't that have the disadvantage of reducing the
accuracy of
> those phases, but it further entangles the whole graph with these extra
uses,
> that are only used on two backends. That seems like added complexity
that
I'm
> not sure is worth it.
Maybe the patch could be simplified to have the second load take the newly
introduced first load as its object input rather than as a separate
input. If
that works the modifications to the graphs could be acceptable; what do
you
think?
We have another similar patch extracting the 'load map' outside
of 'compare
map'
instructions. Like this patch it doesn't impact the benchmarks, but
cleans the
generated code.
This is overall a good idea, since that allows the loads to be GVN'd
together.
However, there will need to be some modifications to check elimination,
since
the load of the map gets the set of maps at the point of the load, not at
the
point of the compare. That is almost like combining load elimination with
check
elimination, but I am not quite sure.
The arch-dependent code in hydrogen.h and hydrogen-instructions.h could
also
be
moved to separate arm64 headers, but I don't think it is preferable.
https://codereview.chromium.org/324093002/
--
--
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.
