From d231efe023a4a22ee2845ff6da3d3e1a733e433b Mon Sep 17 00:00:00 2001 From: Sverker Eriksson Date: Thu, 2 Nov 2017 20:35:11 +0100 Subject: hipe: Add doc sections about limitations --- lib/hipe/doc/src/hipe_app.xml | 73 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) (limited to 'lib/hipe') diff --git a/lib/hipe/doc/src/hipe_app.xml b/lib/hipe/doc/src/hipe_app.xml index e489d155c3..0f8511eb00 100644 --- a/lib/hipe/doc/src/hipe_app.xml +++ b/lib/hipe/doc/src/hipe_app.xml @@ -46,6 +46,79 @@

For on-line help in the Erlang shell, call hipe:help(). Details on HiPE compiler options are given by hipe:help_options().

+
+ Feature Limitations +

+ The HiPE compiler is in general compliant with the normal BEAM compiler, + with respect to semantic behavior. There are however features in the BEAM compiler + and the runtime system that have limited or no support for HiPE compiled modules. +

+ + Stack traces +

Stack traces returned from + erlang:get_stacktrace/0 or as part of 'EXIT' terms + can look incomplete if HiPE compiled functions are involved. Typically a stack trace + will contain only BEAM compiled functions or only HiPE compiled functions, depending + on where the exception was raised.

+

Source code line numbers in stack traces are also not supported by HiPE compiled functions.

+
+ + Tracing +

Modules compiled with HiPE have very limited support for runtime tracing + using erlang:trace_pattern/3.

+
+ + NIFs +

Modules compiled with HiPE can not call + erlang:load_nif/2 to load NIFs.

+
+ + -on_load +

Modules compiled with HiPE can not use + -on_load() + directives.

+
+
+ +
+
+ Performance Limitations +

+ The HiPE compiler does in general produce faster code than the + BEAM compiler. There are however some situation when HiPE + compiled code will perform worse than BEAM code. +

+ + Mode switches +

Every time a process changes from executing code in a + HiPE compiled module to a BEAM compiled module (or vice versa), + it will do a mode switch. This involves a certain amount of + CPU overhead which can have a negative net impact if the + process is switching back and forth without getting enough done in + each mode.

+
+ + Optimization for receive with unique references +

The BEAM compiler can do an optimization when + a receive statement is only waiting for messages + containing a reference created before the receive. All messages + that existed in the queue when the reference was created will be + bypassed, as they cannot possibly contain the reference. HiPE + does not implement this optimization.

+

An example of this is when + gen_server:call() waits for the reply message.

+
+ + Unused list comprehensions +

List comprehensions used only for their side effects, + will be optimized by BEAM to not produce the unused result + list. This optimization is not done by HiPE.

+
+_ = [io:format("~p~n",[N]) || N <- lists:seq(1,10)],
+
+ +
+
SEE ALSO

-- cgit v1.2.3