On Fri, Feb 6, 2015 at 10:30 AM, Steve Fink wrote:
> This looks awesome!
>
> What are the important limitations? I'm guessing it's not going to help
> detect that if only X were true, the register allocator would have avoided
> spilling any registers. I suppose that doesn't fit into "high-level
>
On Fri, Feb 6, 2015 at 8:06 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:
> On 02/06/2015 01:20 AM, Shu-yu Guo wrote:
>
>> I recently landed bug 1030389 to track the high-level optimizations
>> decisions
>> (i.e., deciding what MIR is emitted) made by IonBuilder. This information
This looks awesome!
What are the important limitations? I'm guessing it's not going to help
detect that if only X were true, the register allocator would have
avoided spilling any registers. I suppose that doesn't fit into
"high-level optimization decisions". But what sorts of things could hav
Congrats on landing! Looking forward to seeing this used in the devtools!
On Thu, Feb 5, 2015 at 4:20 PM, Shu-yu Guo wrote:
> Greetings, fellow subtrahend incrementers!
>
> I recently landed bug 1030389 to track the high-level optimizations
> decisions
> (i.e., deciding what MIR is emitted) made
On 02/06/2015 01:20 AM, Shu-yu Guo wrote:
I recently landed bug 1030389 to track the high-level optimizations
decisions
(i.e., deciding what MIR is emitted) made by IonBuilder. This information
will feed into the profiler and is attached to sampled JIT frames.
Not all optimization decisions are
Could this be exposed to the shell, and used in tests to assert that a
particular optimization is applied in a particular situation?
-j
On Thu, Feb 5, 2015 at 6:20 PM, Shu-yu Guo wrote:
> Greetings, fellow subtrahend incrementers!
>
> I recently landed bug 1030389 to track the high-level optimi
6 matches
Mail list logo
