|
|
|
/* @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
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_1" [label="1: Start assign_conditional\nFormals: a:int\nLocals: 0$?%__sil_tmpSIL_temp_conditional___n$2:int& v2:int v1:int \n DECLARE_LOCALS(&return,&0$?%__sil_tmpSIL_temp_conditional___n$2,&v2,&v1); [line 22, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_1" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_11" ;
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_2" [label="2: Exit assign_conditional \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_3" [label="3: Return Stmt \n n$0=*&v1:int [line 25, column 10]\n *&return:int=n$0 [line 25, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_3" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_2" ;
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_4" [label="4: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_4" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_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
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_5" [label="5: Prune (true branch, boolean exp) \n n$3=*&a:int [line 24, column 4]\n PRUNE(n$3, true); [line 24, column 4]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_5" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_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
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_6" [label="6: Prune (false branch, boolean exp) \n n$3=*&a:int [line 24, column 4]\n PRUNE(!n$3, false); [line 24, column 4]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_6" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_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
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_7" [label="7: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$2:int&=&v1 [line 24, column 4]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_7" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_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
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_8" [label="8: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$2:int&=&v2 [line 24, column 4]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_8" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_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
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_9" [label="9: BinaryOperatorStmt: Assign \n n$4=*&0$?%__sil_tmpSIL_temp_conditional___n$2:int& [line 24, column 4]\n *n$4:int=1 [line 24, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_9" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_3" ;
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_10" [label="10: DeclStmt \n *&v2:int=0 [line 23, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_10" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_5" ;
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_10" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_6" ;
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_11" [label="11: DeclStmt \n *&v1:int=0 [line 23, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_11" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_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
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_1" [label="1: Start choose_lvalue\nFormals: a:int\nLocals: v3:int 0$?%__sil_tmpSIL_temp_conditional___n$2:int& v2:int v1:int \n DECLARE_LOCALS(&return,&v3,&0$?%__sil_tmpSIL_temp_conditional___n$2,&v2,&v1); [line 10, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_1" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_11" ;
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_2" [label="2: Exit choose_lvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_3" [label="3: Return Stmt \n n$0=*&v3:int [line 13, column 10]\n *&return:int=n$0 [line 13, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_3" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_2" ;
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_4" [label="4: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_4" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_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
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_5" [label="5: Prune (true branch, boolean exp) \n n$3=*&a:int [line 12, column 12]\n PRUNE(n$3, true); [line 12, column 12]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_5" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_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
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_6" [label="6: Prune (false branch, boolean exp) \n n$3=*&a:int [line 12, column 12]\n PRUNE(!n$3, false); [line 12, column 12]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_6" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_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
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_7" [label="7: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$2:int&=&v1 [line 12, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_7" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_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
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_8" [label="8: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$2:int&=&v2 [line 12, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_8" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_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
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_9" [label="9: DeclStmt \n n$4=*&0$?%__sil_tmpSIL_temp_conditional___n$2:int& [line 12, column 12]\n n$5=*n$4:int [line 12, column 12]\n *&v3:int=n$5 [line 12, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_9" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_3" ;
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_10" [label="10: DeclStmt \n *&v2:int=1 [line 11, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_10" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_5" ;
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_10" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_6" ;
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_11" [label="11: DeclStmt \n *&v1:int=0 [line 11, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_11" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_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
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_1" [label="1: Start choose_rvalue\nFormals: a:int\nLocals: v3:int 0$?%__sil_tmpSIL_temp_conditional___n$2:int v1:int \n DECLARE_LOCALS(&return,&v3,&0$?%__sil_tmpSIL_temp_conditional___n$2,&v1); [line 16, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_1" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_10" ;
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_2" [label="2: Exit choose_rvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_3" [label="3: Return Stmt \n n$0=*&v3:int [line 19, column 10]\n *&return:int=n$0 [line 19, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_3" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_2" ;
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_4" [label="4: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_4" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_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
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_5" [label="5: Prune (true branch, boolean exp) \n n$3=*&a:int [line 18, column 12]\n PRUNE(n$3, true); [line 18, column 12]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_5" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_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
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_6" [label="6: Prune (false branch, boolean exp) \n n$3=*&a:int [line 18, column 12]\n PRUNE(!n$3, false); [line 18, column 12]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_6" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_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
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_7" [label="7: ConditionalStmt Branch \n n$4=*&v1:int [line 18, column 16]\n *&0$?%__sil_tmpSIL_temp_conditional___n$2:int=n$4 [line 18, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_7" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_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
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_8" [label="8: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$2:int=1 [line 18, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_8" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_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
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_9" [label="9: DeclStmt \n n$5=*&0$?%__sil_tmpSIL_temp_conditional___n$2:int [line 18, column 12]\n *&v3:int=n$5 [line 18, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_9" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_3" ;
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_10" [label="10: DeclStmt \n *&v1:int=0 [line 17, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_10" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_5" ;
|
|
|
|
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_10" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_6" ;
|
|
|
|
"div0_assign_conditional#5107071401315365445.4f3bcdea44343998d43cc1b04e1ee179_1" [label="1: Start div0_assign_conditional\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 41, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_assign_conditional#5107071401315365445.4f3bcdea44343998d43cc1b04e1ee179_1" -> "div0_assign_conditional#5107071401315365445.4f3bcdea44343998d43cc1b04e1ee179_3" ;
|
|
|
|
"div0_assign_conditional#5107071401315365445.4f3bcdea44343998d43cc1b04e1ee179_2" [label="2: Exit div0_assign_conditional \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_assign_conditional#5107071401315365445.4f3bcdea44343998d43cc1b04e1ee179_3" [label="3: Return Stmt \n n$0=_fun_assign_conditional(0:int) [line 41, column 44]\n *&return:int=(1 / n$0) [line 41, column 33]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_assign_conditional#5107071401315365445.4f3bcdea44343998d43cc1b04e1ee179_3" -> "div0_assign_conditional#5107071401315365445.4f3bcdea44343998d43cc1b04e1ee179_2" ;
|
|
|
|
"div0_choose_lvalue#13889289797749672490.33434dbd9bc43b011249899260680670_1" [label="1: Start div0_choose_lvalue\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 33, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_choose_lvalue#13889289797749672490.33434dbd9bc43b011249899260680670_1" -> "div0_choose_lvalue#13889289797749672490.33434dbd9bc43b011249899260680670_3" ;
|
|
|
|
"div0_choose_lvalue#13889289797749672490.33434dbd9bc43b011249899260680670_2" [label="2: Exit div0_choose_lvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_choose_lvalue#13889289797749672490.33434dbd9bc43b011249899260680670_3" [label="3: Return Stmt \n n$0=_fun_choose_lvalue(1:int) [line 33, column 39]\n *&return:int=(1 / n$0) [line 33, column 28]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_choose_lvalue#13889289797749672490.33434dbd9bc43b011249899260680670_3" -> "div0_choose_lvalue#13889289797749672490.33434dbd9bc43b011249899260680670_2" ;
|
|
|
|
"div0_choose_rvalue#5985399689822936660.67f1213862b68d51bd848ce28d6859ec_1" [label="1: Start div0_choose_rvalue\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 37, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_choose_rvalue#5985399689822936660.67f1213862b68d51bd848ce28d6859ec_1" -> "div0_choose_rvalue#5985399689822936660.67f1213862b68d51bd848ce28d6859ec_3" ;
|
|
|
|
"div0_choose_rvalue#5985399689822936660.67f1213862b68d51bd848ce28d6859ec_2" [label="2: Exit div0_choose_rvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_choose_rvalue#5985399689822936660.67f1213862b68d51bd848ce28d6859ec_3" [label="3: Return Stmt \n n$0=_fun_choose_rvalue(1:int) [line 37, column 39]\n *&return:int=(1 / n$0) [line 37, column 28]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_choose_rvalue#5985399689822936660.67f1213862b68d51bd848ce28d6859ec_3" -> "div0_choose_rvalue#5985399689822936660.67f1213862b68d51bd848ce28d6859ec_2" ;
|
|
|
|
"div0_temp_lvalue#4236327814744405863.1539dbb4efb081b38036309be4c65715_1" [label="1: Start div0_temp_lvalue\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 45, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_temp_lvalue#4236327814744405863.1539dbb4efb081b38036309be4c65715_1" -> "div0_temp_lvalue#4236327814744405863.1539dbb4efb081b38036309be4c65715_3" ;
|
|
|
|
"div0_temp_lvalue#4236327814744405863.1539dbb4efb081b38036309be4c65715_2" [label="2: Exit div0_temp_lvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_temp_lvalue#4236327814744405863.1539dbb4efb081b38036309be4c65715_3" [label="3: Return Stmt \n n$0=_fun_div_temp_lvalue(1:int,0:int) [line 45, column 33]\n *&return:int=n$0 [line 45, column 26]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div0_temp_lvalue#4236327814744405863.1539dbb4efb081b38036309be4c65715_3" -> "div0_temp_lvalue#4236327814744405863.1539dbb4efb081b38036309be4c65715_2" ;
|
|
|
|
"div1_assign_conditional#703756229606178162.2f3187315131c9e8e31a0380708ebcbb_1" [label="1: Start div1_assign_conditional\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 43, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_assign_conditional#703756229606178162.2f3187315131c9e8e31a0380708ebcbb_1" -> "div1_assign_conditional#703756229606178162.2f3187315131c9e8e31a0380708ebcbb_3" ;
|
|
|
|
"div1_assign_conditional#703756229606178162.2f3187315131c9e8e31a0380708ebcbb_2" [label="2: Exit div1_assign_conditional \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_assign_conditional#703756229606178162.2f3187315131c9e8e31a0380708ebcbb_3" [label="3: Return Stmt \n n$0=_fun_assign_conditional(1:int) [line 43, column 44]\n *&return:int=(1 / n$0) [line 43, column 33]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_assign_conditional#703756229606178162.2f3187315131c9e8e31a0380708ebcbb_3" -> "div1_assign_conditional#703756229606178162.2f3187315131c9e8e31a0380708ebcbb_2" ;
|
|
|
|
"div1_choose_lvalue#17507024914646798803.f2ba997f0baf8ee3dada0c7b0947cb8d_1" [label="1: Start div1_choose_lvalue\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 35, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_choose_lvalue#17507024914646798803.f2ba997f0baf8ee3dada0c7b0947cb8d_1" -> "div1_choose_lvalue#17507024914646798803.f2ba997f0baf8ee3dada0c7b0947cb8d_3" ;
|
|
|
|
"div1_choose_lvalue#17507024914646798803.f2ba997f0baf8ee3dada0c7b0947cb8d_2" [label="2: Exit div1_choose_lvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_choose_lvalue#17507024914646798803.f2ba997f0baf8ee3dada0c7b0947cb8d_3" [label="3: Return Stmt \n n$0=_fun_choose_lvalue(0:int) [line 35, column 39]\n *&return:int=(1 / n$0) [line 35, column 28]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_choose_lvalue#17507024914646798803.f2ba997f0baf8ee3dada0c7b0947cb8d_3" -> "div1_choose_lvalue#17507024914646798803.f2ba997f0baf8ee3dada0c7b0947cb8d_2" ;
|
|
|
|
"div1_choose_rvalue#2897979603329583409.ca29e44a33271dfb3905f48a478bcf9c_1" [label="1: Start div1_choose_rvalue\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 39, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_choose_rvalue#2897979603329583409.ca29e44a33271dfb3905f48a478bcf9c_1" -> "div1_choose_rvalue#2897979603329583409.ca29e44a33271dfb3905f48a478bcf9c_3" ;
|
|
|
|
"div1_choose_rvalue#2897979603329583409.ca29e44a33271dfb3905f48a478bcf9c_2" [label="2: Exit div1_choose_rvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_choose_rvalue#2897979603329583409.ca29e44a33271dfb3905f48a478bcf9c_3" [label="3: Return Stmt \n n$0=_fun_choose_rvalue(0:int) [line 39, column 39]\n *&return:int=(1 / n$0) [line 39, column 28]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_choose_rvalue#2897979603329583409.ca29e44a33271dfb3905f48a478bcf9c_3" -> "div1_choose_rvalue#2897979603329583409.ca29e44a33271dfb3905f48a478bcf9c_2" ;
|
|
|
|
"div1_temp_lvalue#14722162998333319062.760b52102ce508c3244378cf1bf06b6d_1" [label="1: Start div1_temp_lvalue\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 47, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_temp_lvalue#14722162998333319062.760b52102ce508c3244378cf1bf06b6d_1" -> "div1_temp_lvalue#14722162998333319062.760b52102ce508c3244378cf1bf06b6d_3" ;
|
|
|
|
"div1_temp_lvalue#14722162998333319062.760b52102ce508c3244378cf1bf06b6d_2" [label="2: Exit div1_temp_lvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_temp_lvalue#14722162998333319062.760b52102ce508c3244378cf1bf06b6d_3" [label="3: Return Stmt \n n$0=_fun_div_temp_lvalue(0:int,1:int) [line 47, column 33]\n *&return:int=n$0 [line 47, column 26]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div1_temp_lvalue#14722162998333319062.760b52102ce508c3244378cf1bf06b6d_3" -> "div1_temp_lvalue#14722162998333319062.760b52102ce508c3244378cf1bf06b6d_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
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_1" [label="1: Start div_temp_lvalue\nFormals: a:int b:int\nLocals: r:int const & 0$?%__sil_tmpSIL_temp_conditional___n$4:int 0$?%__sil_tmpSIL_materialize_temp__n$3:int const \n DECLARE_LOCALS(&return,&r,&0$?%__sil_tmpSIL_temp_conditional___n$4,&0$?%__sil_tmpSIL_materialize_temp__n$3); [line 28, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_1" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_5" ;
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_1" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_6" ;
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_2" [label="2: Exit div_temp_lvalue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_3" [label="3: Return Stmt \n n$0=*&r:int const & [line 30, column 14]\n n$1=*n$0:int [line 30, column 14]\n *&return:int=(1 / n$1) [line 30, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_3" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_2" ;
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_4" [label="4: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_4" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_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
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_5" [label="5: Prune (true branch, boolean exp) \n n$5=*&a:int [line 29, column 18]\n PRUNE(n$5, true); [line 29, column 18]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_5" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_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
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_6" [label="6: Prune (false branch, boolean exp) \n n$5=*&a:int [line 29, column 18]\n PRUNE(!n$5, false); [line 29, column 18]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_6" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_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
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_7" [label="7: ConditionalStmt Branch \n n$6=*&b:int [line 29, column 22]\n *&0$?%__sil_tmpSIL_temp_conditional___n$4:int=n$6 [line 29, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_7" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_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
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_8" [label="8: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$4:int=1 [line 29, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_8" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_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
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_9" [label="9: DeclStmt \n n$7=*&0$?%__sil_tmpSIL_temp_conditional___n$4:int [line 29, column 18]\n *&0$?%__sil_tmpSIL_materialize_temp__n$3:int=n$7 [line 29, column 18]\n *&r:int const &=&0$?%__sil_tmpSIL_materialize_temp__n$3 [line 29, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_9" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_3" ;
|
|
|
|
}
|