On 2015/06/02 16:05:00, caitp wrote:
On 2015/06/02 14:55:18, caitp wrote:
> On 2015/06/02 12:47:23, caitp wrote:
> > The output from --trace-turbo-graph looks generally okay (at least the
> portions
> > that I understand). So I'm not sure what's causing the arm64 sim test
to
fail.
> > https://gist.githubusercontent.com/caitp/20f4ba77fc0d03033552/raw/log
for
a
> > (big) log with --trace-turbo and --trace-turbo-graph.
>
> mstarzinger@ I was wondering if you (or someone else familiar with TF)
might
be
> able to shed some light on where this is going wrong on ARM64, or how I
could
> determine it. The --trace-turbo-graph output for the function looks
correct,
but
> we still end up with a kLetBindingReInitialization bailout, only on
ARM64,
and
> only with turbofan.
From IRC:
[12:03] <caitp> you know what
[12:04] <caitp> replacing `if (FLAG_debug_code && op == Token::INIT_LET)
{`
with `if (generate_debug_code_ && op == Token::INIT_LET) {` in
full-codegen-arm64.cc fixes it
[12:04] <caitp> and matches the other arches better
[12:04] <caitp> derp
so... I assume that's just a bug in full-codegen-arm64 unless this was
written
this way on purpose?
Anyways, looking into this more, I don't think it's strictly a TF issue but
maybe more related to deoptimization, and probably the desugaring itself is
slightly suspect since it's doing this bad of a job of it.
For whatever reason, after de-opt, let bindings are re-assigned and
re-initialized. Maybe during deoptimization or OSR, these variable
initializations should be skipped somehow? I'm not sure the approach to take
with this, but I guess this is still not ready to land
https://codereview.chromium.org/1127063003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
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 v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
