On 2014/12/06 00:03:49, adamk wrote:
On 2014/12/05 23:57:14, adamk wrote:
> On 2014/12/05 23:40:59, Dmitry Lomov (chromium) wrote:
> > On 2014/12/05 23:14:27, adamk wrote:
> > > Okay, this time it should really be fixed. I searched for all
numeric
> > operations
> > > and added kCanOverflow flags. Not loving the manual process of
that, but
at
> > > least I now understand what the failure was.
> >
> > Right, I see. I'll take a careful look. How can we verify that all
those
> > operations really do not overflow?
>
> Some of them are obvious, like subtracting 1 from the number of buckets
(it
can
> never be < 4).
>
> The ones that aren't so obvious are ones that calculate an element or
bucket
> index. But my intuiotion is that we'd have run out of memory before any
of
those
> would overflow.
Any thoughts on the underlying deopt issue? This seems like either a flaw
in
the
way we write Hydrogen code today or a flaw in the
INLINE_OPTIMIZED_FUNCTION
list.
None of INLINE_OPTIMIZED_FUNCTIONS should ever deopt. (Since they do not
learn,
there is no assumptions that might turn out to be false).
Fundamentally, when we write hydrogen for them we should ensure there is no
deopt points.
Not sure how to assert that or even if it is worthwhile (you are just
unlucky in
that your code does a lot of arithmetic)
https://codereview.chromium.org/782073002/
--
--
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.
