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
Interpreting the output of ``@code_warntype``, like that of its cousins
659
+
``@code_lowered``, ``@code_typed``, ``@code_llvm``, and
660
+
``@code_native``, takes a little practice. Your
661
+
code is being presented in form that has been partially-digested on
662
+
its way to generating compiled machine code. Most of the expressions
663
+
are annotated by a type, indicated by the ``::T`` (where ``T`` might
664
+
be ``Float64``, for example). The particular characteristic of
665
+
``@code_warntype`` is that non-concrete types are displayed in red; in
666
+
the above example, such output is shown in all-caps.
667
+
668
+
The first line of the output, beginning with ``1-element Array``,
669
+
simply means that there is only one method that matches the function
670
+
and input types you provided. The next line of the output summarizes
671
+
information about the different variables. You can see that ``y``, one
672
+
of the variables you created, is a ``Union(Float64,Int64)``, due to
673
+
the type-instability of ``pos``. There is another variable,
674
+
``_var1``, which you can see also has the same type.
675
+
676
+
The next lines represent the body of ``f``. The lines starting with a
677
+
number followed by a colon (``1:``, ``2:``) are labels, and represent
678
+
targets for jumps (via ``goto``) in your code. Looking at the body,
679
+
you can see that ``pos`` has been *inlined* into ``f``---everything
680
+
before ``2:`` comes from code defined in ``pos``.
681
+
682
+
Starting at ``2:``, the variable ``y`` is defined, and again annotated
683
+
as a ``Union`` type. Next, we see that the compiler created the
684
+
temporary variable ``_var1`` to hold the result of ``y*x``; it too is
685
+
type-unstable. However, at the next line, all type-instability ends:
686
+
because ``sin`` converts integer inputs into ``Float64``, the final
687
+
return value of ``f`` is a ``Float64``. So calls of the form
688
+
``f(x::Float64)`` will not be type-unstable in their output, even if
689
+
some of the intermediate computations are type-unstable.
690
+
691
+
How you use this information is up to you. Obviously, it would be far
692
+
and away best to fix ``pos`` to be type-stable: if you did so, all of
693
+
the variables in ``f`` would be concrete, and its performance would be
694
+
optimal. However, there are circumstances where this kind of
695
+
*ephemeral* type instability might not matter too much: for example,
696
+
if ``pos`` is never used in isolation, the fact that ``f``\'s output
697
+
is type-stable (for ``Float64`` inputs) will shield later code from
698
+
the propagating effects of type instability. This is particularly
699
+
relevant in cases where fixing the type instability is difficult or
700
+
impossible: for example, currently it's not possible to infer the
701
+
return type of an anonymous function. In such cases, the tips above
702
+
(e.g., adding type annotations and/or breaking up functions) are your
703
+
best tools to contain the "damage" from type instability.
704
+
705
+
Here is a table which can help you interpret expressions marked as
706
+
containing non-leaf types:
707
+
708
+
.. |I0| replace:: Interpretation
709
+
.. |F0| replace:: Possible fix
710
+
.. |I1| replace:: Function with unstable return type
711
+
.. |F1| replace:: Make the return value type-stable, even if you have to annotate it
712
+
.. |I2| replace:: Call to a type-unstable function
713
+
.. |F2| replace:: Fix the function, or annotate the return value
714
+
.. |I3| replace:: Accessing elements of poorly-typed arrays
715
+
.. |F3| replace:: Use arrays with better-defined types, or annotate the type of individual element accesses
716
+
.. |I4| replace:: Getting a field that is of non-leaf type. In this case, ``ArrayContainer`` had a field ``data::Array{T}``. But ``Array`` needs the dimension ``N``, too.
717
+
.. |F4| replace:: Use concrete types like ``Array{T,3}`` or ``Array{T,N}``, where ``N`` is now a parameter of ``ArrayContainer``
Copy file name to clipboardExpand all lines: doc/stdlib/base.rst
+8Lines changed: 8 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -6441,6 +6441,14 @@ Internals
6441
6441
6442
6442
Evaluates the arguments to the function call, determines their types, and calls the ``code_typed`` function on the resulting expression
6443
6443
6444
+
.. function:: code_warntype(f, types)
6445
+
6446
+
Returns an array of lowered and type-inferred ASTs for the methods matching the given generic function and type signature. The ASTs are annotated in such a way as to cause "non-leaf" types to be displayed in red. This serves as a warning of potential type instability. Not all non-leaf types are particularly problematic for performance, so the results need to be used judiciously. See :ref:`man-code-warntype` for more information.
6447
+
6448
+
.. function:: @code_warntype
6449
+
6450
+
Evaluates the arguments to the function call, determines their types, and calls the ``code_warntype`` function on the resulting expression
6451
+
6444
6452
.. function:: code_llvm(f, types)
6445
6453
6446
6454
Prints the LLVM bitcodes generated for running the method matching the given generic function and type signature to STDOUT.
0 commit comments