|
|
|
|
/* @generated */
|
|
|
|
|
digraph cfg {
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_1" [label="1: Start binary_conditional::binaryConditional\nFormals: \nLocals: x:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X 0$?%__sil_tmpSIL_temp_conditional___n$9:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X a:binary_conditional::X \n DECLARE_LOCALS(&return,&x,&0$?%__sil_tmpSIL_materialize_temp__n$6,&0$?%__sil_tmpSIL_temp_conditional___n$9,&0$?%__sil_tmpSIL_materialize_temp__n$5,&a); [line 22, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_1" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_12" ;
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_2" [label="2: Exit binary_conditional::binaryConditional \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_3" [label="3: Destruction \n _=*&x:binary_conditional::X [line 25, column 1]\n n$1=_fun_binary_conditional::X_~X(&x:binary_conditional::X*) [line 25, column 1]\n _=*&a:binary_conditional::X [line 25, column 1]\n n$3=_fun_binary_conditional::X_~X(&a:binary_conditional::X*) [line 25, column 1]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_3" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_2" ;
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_4" [label="4: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_4" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_11" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_5" [label="5: Call _fun_binary_conditional::X_operator_bool \n _=*&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X [line 24, column 9]\n n$11=_fun_binary_conditional::X_operator_bool(&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X&) [line 24, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_5" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_6" ;
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_5" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_7" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_6" [label="6: Prune (true branch, boolean exp) \n PRUNE(n$11, true); [line 24, column 9]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_6" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_8" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_7" [label="7: Prune (false branch, boolean exp) \n PRUNE(!n$11, false); [line 24, column 9]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_7" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_9" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_8" [label="8: ConditionalStmt Branch \n n$12=_fun_binary_conditional::X_X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*,&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X&) [line 24, column 9]\n *&0$?%__sil_tmpSIL_temp_conditional___n$9:binary_conditional::X=&0$?%__sil_tmpSIL_materialize_temp__n$5 [line 24, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_8" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_4" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_9" [label="9: ConditionalStmt Branch \n n$13=_fun_binary_conditional::X_X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*,&a:binary_conditional::X&) [line 24, column 19]\n *&0$?%__sil_tmpSIL_temp_conditional___n$9:binary_conditional::X=&0$?%__sil_tmpSIL_materialize_temp__n$5 [line 24, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_9" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_4" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_10" [label="10: BinaryConditionalStmt Init \n n$8=_fun_binary_conditional::getX(&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X*) [line 24, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_10" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_5" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_11" [label="11: DeclStmt \n n$14=*&0$?%__sil_tmpSIL_temp_conditional___n$9:binary_conditional::X [line 24, column 9]\n *&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X=n$14 [line 24, column 9]\n n$15=_fun_binary_conditional::X_X(&x:binary_conditional::X*,&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X&) [line 24, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_11" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_3" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_12" [label="12: DeclStmt \n n$16=_fun_binary_conditional::X_X(&a:binary_conditional::X*) [line 23, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_12" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_10" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_1" [label="1: Start binary_conditional::conditional\nFormals: \nLocals: x:binary_conditional::X 0$?%__sil_tmpSIL_temp_conditional___n$6:binary_conditional::X 0$?%__sil_tmp__temp_return_n$8:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$11:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X a:binary_conditional::X \n DECLARE_LOCALS(&return,&x,&0$?%__sil_tmpSIL_temp_conditional___n$6,&0$?%__sil_tmp__temp_return_n$8,&0$?%__sil_tmpSIL_materialize_temp__n$11,&0$?%__sil_tmpSIL_materialize_temp__n$5,&a); [line 27, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_1" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_11" ;
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_2" [label="2: Exit binary_conditional::conditional \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_3" [label="3: Destruction \n _=*&x:binary_conditional::X [line 30, column 1]\n n$1=_fun_binary_conditional::X_~X(&x:binary_conditional::X*) [line 30, column 1]\n _=*&a:binary_conditional::X [line 30, column 1]\n n$3=_fun_binary_conditional::X_~X(&a:binary_conditional::X*) [line 30, column 1]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_3" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_2" ;
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_4" [label="4: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_4" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_10" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_5" [label="5: Call _fun_binary_conditional::X_operator_bool \n n$9=_fun_binary_conditional::getX(&0$?%__sil_tmp__temp_return_n$8:binary_conditional::X*) [line 29, column 9]\n n$10=_fun_binary_conditional::X_operator_bool(&0$?%__sil_tmp__temp_return_n$8:binary_conditional::X&) [line 29, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_5" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_6" ;
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_5" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_7" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_6" [label="6: Prune (true branch, boolean exp) \n PRUNE(n$10, true); [line 29, column 9]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_6" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_8" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_7" [label="7: Prune (false branch, boolean exp) \n PRUNE(!n$10, false); [line 29, column 9]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_7" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_9" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_8" [label="8: ConditionalStmt Branch \n n$13=_fun_binary_conditional::getX(&0$?%__sil_tmpSIL_materialize_temp__n$11:binary_conditional::X*) [line 29, column 18]\n n$14=_fun_binary_conditional::X_X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*,&0$?%__sil_tmpSIL_materialize_temp__n$11:binary_conditional::X&) [line 29, column 18]\n *&0$?%__sil_tmpSIL_temp_conditional___n$6:binary_conditional::X=&0$?%__sil_tmpSIL_materialize_temp__n$5 [line 29, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_8" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_4" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_9" [label="9: ConditionalStmt Branch \n n$15=_fun_binary_conditional::X_X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*,&a:binary_conditional::X&) [line 29, column 27]\n *&0$?%__sil_tmpSIL_temp_conditional___n$6:binary_conditional::X=&0$?%__sil_tmpSIL_materialize_temp__n$5 [line 29, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_9" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_4" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_10" [label="10: DeclStmt \n n$16=*&0$?%__sil_tmpSIL_temp_conditional___n$6:binary_conditional::X [line 29, column 9]\n *&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X=n$16 [line 29, column 9]\n n$17=_fun_binary_conditional::X_X(&x:binary_conditional::X*,&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X&) [line 29, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_10" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_3" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_11" [label="11: DeclStmt \n n$18=_fun_binary_conditional::X_X(&a:binary_conditional::X*) [line 28, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_11" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_5" ;
|
|
|
|
|
"getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_1" [label="1: Start binary_conditional::getX\nFormals: __return_param:binary_conditional::X*\nLocals: x:binary_conditional::X \n DECLARE_LOCALS(&return,&x); [line 16, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_1" -> "getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_4" ;
|
|
|
|
|
"getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_2" [label="2: Exit binary_conditional::getX \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_3" [label="3: Return Stmt \n n$0=*&__return_param:binary_conditional::X* [line 18, column 3]\n n$1=_fun_binary_conditional::X_X(n$0:binary_conditional::X*,&x:binary_conditional::X&) [line 18, column 10]\n _=*&x:binary_conditional::X [line 18, column 10]\n n$3=_fun_binary_conditional::X_~X(&x:binary_conditional::X*) [line 18, column 10]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_3" -> "getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_2" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_4" [label="4: DeclStmt \n n$5=_fun_binary_conditional::X_X(&x:binary_conditional::X*) [line 17, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_4" -> "getX#binary_conditional#7708042186122353096.ec6c66051810049a5e5688caadbf0f96_3" ;
|
|
|
|
|
"X#X#binary_conditional#{14263889156663411855|constexpr}.2259daea109ab4ed7cb747998c1a8b38_1" [label="1: Start binary_conditional::X_X\nFormals: this:binary_conditional::X*\nLocals: \n DECLARE_LOCALS(&return); [line 12, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"X#X#binary_conditional#{14263889156663411855|constexpr}.2259daea109ab4ed7cb747998c1a8b38_1" -> "X#X#binary_conditional#{14263889156663411855|constexpr}.2259daea109ab4ed7cb747998c1a8b38_2" ;
|
|
|
|
|
"X#X#binary_conditional#{14263889156663411855|constexpr}.2259daea109ab4ed7cb747998c1a8b38_2" [label="2: Exit binary_conditional::X_X \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"X#X#binary_conditional#{984623546922473120|constexpr}.75245961304dd439037ceba4c9251935_1" [label="1: Start binary_conditional::X_X\nFormals: this:binary_conditional::X* __param_0:binary_conditional::X&\nLocals: \n DECLARE_LOCALS(&return); [line 12, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"X#X#binary_conditional#{984623546922473120|constexpr}.75245961304dd439037ceba4c9251935_1" -> "X#X#binary_conditional#{984623546922473120|constexpr}.75245961304dd439037ceba4c9251935_2" ;
|
|
|
|
|
"X#X#binary_conditional#{984623546922473120|constexpr}.75245961304dd439037ceba4c9251935_2" [label="2: Exit binary_conditional::X_X \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"X#X#binary_conditional#{9863553346576066468|constexpr}.13550d5872419d596c3c38205883714d_1" [label="1: Start binary_conditional::X_X\nFormals: this:binary_conditional::X* __param_0:binary_conditional::X const &\nLocals: \n DECLARE_LOCALS(&return); [line 12, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"X#X#binary_conditional#{9863553346576066468|constexpr}.13550d5872419d596c3c38205883714d_1" -> "X#X#binary_conditional#{9863553346576066468|constexpr}.13550d5872419d596c3c38205883714d_2" ;
|
|
|
|
|
"X#X#binary_conditional#{9863553346576066468|constexpr}.13550d5872419d596c3c38205883714d_2" [label="2: Exit binary_conditional::X_X \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_1" [label="1: Start binary_conditional::X_operator_bool\nFormals: this:binary_conditional::X*\nLocals: \n DECLARE_LOCALS(&return); [line 13, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_1" -> "operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_3" ;
|
|
|
|
|
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_2" [label="2: Exit binary_conditional::X_operator_bool \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_3" [label="3: Return Stmt \n *&return:_Bool=1 [line 13, column 21]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_3" -> "operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_2" ;
|
|
|
|
|
}
|
