Created attachment 8559066[details][diff][review]
Patch
We should specialize based on TI (by adding a typebarrier) when the MIRType is MIRType_Float and TI says the output is MIRType_Double. MIRType_Float is more narrow than MIRType_Double

Comment on attachment 8559066[details][diff][review]
Patch
Review of attachment 8559066[details][diff][review]:
-----------------------------------------------------------------
Thanks for jumping in! Does it fix the regression?
::: js/src/jit/IonBuilder.cpp
@@ +4505,5 @@
> + MIRType observedType = types->getKnownMIRType();
> +
> + // Don't specialize if type is MIRType_Float32 and TI reports
> + // MIRType_Double. Float is more specific than double.
> + if (observedType == MIRType_Double && rdef->type() == MIRType_Float32)
In some cases, it could be that the observed type is even MIRType_Int32 (e.g. for (var i = 0; i < 1000; i++) Math.fround(i);), could we make the first part of the condition IsNumberType(observedType), instead?

Answer to the question:
> <h4writer> bbouvier, about the suggestion. That would be counter-productive. MIRType_Int32 is more specialized than MIRType_Float32. So in that case it is better to specialize ;)
> * Jesse has quit (Client exited)
> <bbouvier> h4writer: yes, but what if we've used Math.fround? (which creates the MIRType_Float32 in the first place)
> <bbouvier> h4writer: TI will say it only saw Int32, but the real type is and should actually be Float32, no?
> <h4writer> bbouvier, TI will indeed say it saw Int32, which is correct. If we can optimize all uses of the result of Math.fround to be int32 that would be much faster than using float arithmetics
> <h4writer> bbouvier, as soon as we hit a float32, TI will say double
> <h4writer> bbouvier, so Math.fround means we want to round to float32. doesn't imply we definitely need to use float32
> <bbouvier> h4writer: okay, thanks for explaining :)
Secondly:
Yes it fixes the regression ;)