You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When optimizing a side exit, it would be useful to know what types and values are guaranteed. Many side traces start with guards that are unnecessary as the type of values is guaranteed by the previous executor.
However, we do not currently use that information when optimizing side guards.
If we were to record that information on exits, then we could do a better job optimizing exits.
For example, given the following code snippet:
x=a+b# intsif (cond): # Not takenreturnx+a+b
If there is a side exit at the branch if(cond), then we should know that x, a and b are ints, but we throw that information away, resulting in extra guards in the final trace for return x + a + b
One record per executor
Instead of retaining type information on side exits, we can keep the type information at the entry to the trace and recompute the type information before optimizing the new side trace.
(Credit @Fidget-Spinner)
Although this would slow down the optimizer a bit, it would save quite a lot of memory.
The text was updated successfully, but these errors were encountered:
When optimizing a side exit, it would be useful to know what types and values are guaranteed. Many side traces start with guards that are unnecessary as the type of values is guaranteed by the previous executor.
However, we do not currently use that information when optimizing side guards.
If we were to record that information on exits, then we could do a better job optimizing exits.
For example, given the following code snippet:
If there is a side exit at the branch
if(cond)
, then we should know thatx
,a
andb
are ints, but we throw that information away, resulting in extra guards in the final trace forreturn x + a + b
One record per executor
Instead of retaining type information on side exits, we can keep the type information at the entry to the trace and recompute the type information before optimizing the new side trace.
(Credit @Fidget-Spinner)
Although this would slow down the optimizer a bit, it would save quite a lot of memory.
The text was updated successfully, but these errors were encountered: