On 2015/08/27 20:01:29, titzer wrote:
On 2015/08/27 19:55:36, Michael Starzinger wrote:
>
https://codereview.chromium.org/1321663003/diff/40001/test/cctest/interpreter/test-bytecode-generator.cc
> File test/cctest/interpreter/test-bytecode-generator.cc (right):
>
>
https://codereview.chromium.org/1321663003/diff/40001/test/cctest/interpreter/test-bytecode-generator.cc#newcode257
> test/cctest/interpreter/test-bytecode-generator.cc:257: { 3.14, 3.14 }
> On 2015/08/27 19:36:29, Michael Starzinger wrote:
> > On 2015/08/27 16:34:07, rmcilroy wrote:
> > > Michi - looks like double literals aren't de-duped by the parser
(we get
a
> new
> > > HeapNumber each time). Is this done elsewhere or have we always had
a
new
> > > HeapNumber for each double literal?
> >
> > Not sure I understand your comment correctly. How would the parser
de-dupe
> > literals? That would make the AST degenerate into a DAG if we would do
that.
> Or
> > am I missing something here?
> >
> > Compilers can de-dupe the values. One mechanism of de-duping would be
GVN
> which
> > makes sure that identical nodes in the graph are coalesced. Both
Hydrogen
and
> > TurboFan do that.
>
> Ah, I think now I understand where you are coming from, I think your
question
> was whether AstValue::Internalize should canonicalize HeapNumbers or
not.
Maeh,
> the data-structure for canonicalizing them would probably end up eating
more
> memory than the duped HeapNumbers, I don't think that would buy us
anything
> besides complexity.
>
> Rather the question is, why do we "internalize" double literals in the
first
> place. One could argue that it should be the responsibility of the
compiler
to
> decide whether and where to allocate HeapNumbers. But that's opening a
can
of
> worms. I suggest we don't go there.
The JSGraph in TurboFan de-dupes all constants (including HeapNumbers),
except
other HeapObjects. I agree with Michi that the parser shouldn't try to
de-dup
doubles; it's probably not worth it.
Right, sorry I wasn't so clear here. I meant canonicalizing doubles, not
GVN or
anything like that. I wasn't suggesting we change the parser to do this, I
just
wanted to make sure I wasn't missing something (e.g., Strings are
canonicalized,
just wanted to make sure I wasn't missing something similar for double
literals).
If we were going to this I agree it should be the responsibility of the
compliler / bytecode-array-builder (only canonicaling on a per-function
level),
but it seems from your comments that this is unlikely to be much of a
benefit,
so I'm quite happy to leave it as a comment for now and possibly
investigate it
later once we can run real JS.
https://codereview.chromium.org/1321663003/
--
--
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.
