At present, the verifier computes the type NULL for OP_applytype, but much more is frequently known about the type, and by making that information available we allow operations that use the value computed by OP_applytype (such as OP_construct) to be specialized at compile time. In turn, the type of the value returned from the OP_construct will also be known. The cumulative effect is to speed up the evaluation of expressions such as vector initializers and operations on them.
Created attachment 557109 [details] [diff] [review] Infer the types for OP_applytype Infer the result type of OP_applytype, under static versioning. This patch by itself - no changes to the code generator - yields good speedups on the benchmarks attached to bug #532690, speeding vector-init-1 from 282 to 338 it/sec (speedup=1.20) and vector-init-2 from 361 to 424 it/sec (speedup=1.17). Measurements were taken with various other pending optimization applied (notably inlining of vector writes, bug #599099). I guess the main question about this patch is whether the handling and creation of traits in the Vector.<C> case - non-primitive types - is correct, and if not, whether it can be made correct by adding guards that will succeed often in practice.
Verifier.cpp:1802: ... is factoring desireable? yup, desireable. maybe add an api in DomainMgr that takes param_ctraits and returns the possibly cached, created-on-demand new vector ctraits? The explicit string wrangling makes me nervous but given no other api, there's nothing obviously wrong about it. weird for surface syntax to show up here, ya know?