1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
BEAM SSA Checks
===============
While developing optimizations operating on the BEAM SSA it is often
hard to check that various transforms have the intended effect. For
example, unless a transform produces crashing code, it is hard to
detect that the transform is broken. Likewise missing an optimization
opportunity is also hard to detect.
To simplify the creation of tests on BEAM SSA the compiler has an
internal mode in which it parses and checks assertions on the
structure and content of the produced BEAM SSA code. This is a short
introduction to the syntax and semantics of the SSA checker
functionality.
Syntax
------
SSA checks are embedded in the source code as comments starting with
with one of `%ssa%`, `%%ssa%` or `%%%ssa%`. This is a short
introduction the syntax, for the full syntax please refer to the
`ssa_check_when_clause` production in `erl_parse.yrl`.
SSA checks can be placed inside any Erlang function, for example:
t0() ->
%ssa% () when post_ssa_opt ->
%ssa% ret(#{}).
#{}.
will check that `t0/0` returns the literal `#{}`. If we want to check
that a function returns its first formal parameter, we can write:
t1(A, _B) ->
%ssa% (X, _) when post_ssa_opt ->
%ssa% ret(X).
A.
Note how we match the first formal parameter using `X`. The reason for
having our own formal parameters for the SSA check, is that we don't
want to introduce new identifiers at the Erlang level to support
SSA-level checks. Consider if `t1/2` had been defined as `t1([A|As],
B)` we would have had to introduce a new identifier for the aggregate
value `[A|As]`.
The full syntax for a SSA check clause is:
<expected-result>? (<formals>) when <pipeline-location> -> <checks> '.'
where `<expected-result>` can be one of `pass` (the check must
succeed), `fail` and `xfail` (the check must fail). Omitting
`<expected-result>` is parsed as an implicit `pass`.
`<formals>` is a comma-separated list of variables.
`<pipeline-location>` specifies when in the compiler pipeline to run
the checks. For now the only supported value for `<pipeline-location>`
is `post_ssa_opt` which runs the checks after the `ssa_opt` pass.
`<checks>` is a comma-separated list of matches against the BEAM SSA
code. For non-flow-control operations the syntax is:
<variable> = <operation> ( <arguments> ) <annotation>?
where `<operation>` is the `#b_set.op` field from the internal SSA
representation. BIFs are written as `bif:<atom>`.
`<arguments>` is a comma-separated list of variables or literals.
For flow control operations and labels, the syntax is as follows:
br(<bool>, <true-label>, <false-label>)
switch(<value>, <fail-label>, [{<label>,<value>},...])
ret(<value>)
label <value>
where `<value>` is a literal or a variable.
A check can also include an assertion on operation annotations. The
assertion is written as a map-like pattern following the argument
list, for example:
t0() ->
%ssa% () when post_ssa_opt ->
%ssa% _ = call(fun return_int/0) { result_type => {t_integer,{17,17}},
%ssa% location => {_,32} },
%ssa% _ = call(fun return_tuple/0) {
%ssa% result_type => {t_tuple,2,true,#{1 => {t_integer,{1,1}},
%ssa% 2 => {t_integer,{2,2}}}}
%ssa% }.
X = return_int(),
Y = return_tuple(),
{X, Y}.
Semantics
---------
When an SSA assertion is matched against the BEAM SSA for a function,
patterns are applied sequentially. If the current pattern doesn't
match, the checker tries with the next instruction. If the checker
reaches the end of the SSA representation without having matched all
patterns, the check is considered failed otherwise the assertion is
considered successful. When a pattern is matched against an SSA
operation, the values of variables already bound are considered and if
the patterns matches, free variables introduced in the successfully
matched pattern are bound to the values they have in the matched
operation.
Compiler integration
--------------------
The BEAM SSA checker is enabled by the compiler option
`{check_ssa,post_ssa_opt}`. When enabled, a failed SSA assertion will
be reported using the same mechanisms as an ordinary compilation
error.
Limitations
-----------
* Unbound variables are not allowed in the key-part of map literals nor
in annotation assertions.
|
