Closed Bug 952286 Opened 11 years ago Closed 10 years ago

AWFY: 18% regression on x86 asmjs-ubench-skinning

Categories

(Core :: JavaScript Engine: JIT, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: luke, Unassigned)

References

Details

(Keywords: regression)

I'm unable to reproduce this so far. IONFLAGS=codegen output between a2a5e25445e5 and afe7a6c2c9b2 contains identical instructions on 32-bit x86 Linux.
(In reply to Dan Gohman [:sunfish] from comment #1)
> I'm unable to reproduce this so far. IONFLAGS=codegen output between
> a2a5e25445e5 and afe7a6c2c9b2 contains identical instructions on 32-bit x86
> Linux.

You did run with --no-asmjs right?
(In reply to Hannes Verschore [:h4writer] from comment #2)
> (In reply to Dan Gohman [:sunfish] from comment #1)
> > I'm unable to reproduce this so far. IONFLAGS=codegen output between
> > a2a5e25445e5 and afe7a6c2c9b2 contains identical instructions on 32-bit x86
> > Linux.
> 
> You did run with --no-asmjs right?

No, I didn't think this bug was about --no-asmjs mode. But now I have, and I don't see a codegen difference between those revisions with --no-asmjs either.
I should have been more explicit, but this was an Odin (--asmjs) regression; --no-asmjs was unaffected.
I am not able to reproduce the regression locally either.  Looking again, GGC and the default build basically switched scores starting with the cset range in question.  Normally, GGC and the default build get the exact same score on asm.js code since practically 100% of the time is in generated code.  This all strongly smells like some artifact of code/data alignment or caching or something else not at all related to Dan's patches.  Thus, I think we can resolve this particular bug INVALID unless someone thinks something else is afoot.  Sorry for the noise Dan!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.