|
|
|
|
/* @generated */
|
|
|
|
|
digraph cfg {
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_1" [label="1: Start g0\nFormals: \nLocals: a:int \n DECLARE_LOCALS(&return,&a); [line 14, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_1" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_12" ;
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_2" [label="2: Exit g0 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_3" [label="3: Return Stmt \n *&return:int=1 [line 23, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_3" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_2" ;
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_4" [label="4: BinaryOperatorStmt: Assign \n *&a:int=1 [line 22, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_4" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_3" ;
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_5" [label="5: Skip GotoLabel_stepD \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_5" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_4" ;
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_6" [label="6: Skip GotoLabel_stepC \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_6" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_5" ;
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_7" [label="7: Skip GotoLabel_stepB \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_7" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_6" ;
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_8" [label="8: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_8" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_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
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_9" [label="9: BinaryOperatorStmt: GT \n n$3=_fun_getValue() [line 16, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_9" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_10" ;
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_9" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_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
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_10" [label="10: Prune (true branch, if) \n PRUNE((n$3 > 1), true); [line 16, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_10" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_6" ;
|
[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
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_11" [label="11: Prune (false branch, if) \n PRUNE(!(n$3 > 1), false); [line 16, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_11" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_8" ;
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_12" [label="12: DeclStmt \n *&a:int=0 [line 15, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g0.8ac829e3bb8338d74cfb45ebe834d8e1_12" -> "g0.8ac829e3bb8338d74cfb45ebe834d8e1_9" ;
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_1" [label="1: Start g1\nFormals: \nLocals: a:int \n DECLARE_LOCALS(&return,&a); [line 26, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_1" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_11" ;
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_2" [label="2: Exit g1 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_3" [label="3: Return Stmt \n *&return:int=1 [line 34, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_3" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_2" ;
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_4" [label="4: BinaryOperatorStmt: Assign \n *&a:int=1 [line 33, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_4" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_3" ;
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_5" [label="5: Skip GotoLabel_stepB \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_5" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_4" ;
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_6" [label="6: Return Stmt \n *&return:int=0 [line 30, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_6" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_2" ;
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_7" [label="7: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_7" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_6" ;
|
[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
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_8" [label="8: BinaryOperatorStmt: GT \n n$1=_fun_getValue() [line 28, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_8" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_9" ;
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_8" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_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
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_9" [label="9: Prune (true branch, if) \n PRUNE((n$1 > 1), true); [line 28, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_9" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_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
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_10" [label="10: Prune (false branch, if) \n PRUNE(!(n$1 > 1), false); [line 28, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_10" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_7" ;
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_11" [label="11: DeclStmt \n *&a:int=0 [line 27, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g1.0120a4f9196a5f9eb9f523f31f914da7_11" -> "g1.0120a4f9196a5f9eb9f523f31f914da7_8" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_1" [label="1: Start g2\nFormals: \nLocals: a:int \n DECLARE_LOCALS(&return,&a); [line 37, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_1" -> "g2.e1c80488853d86ab9d6decfe30d8930f_24" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_2" [label="2: Exit g2 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_3" [label="3: Return Stmt \n *&return:int=1 [line 56, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_3" -> "g2.e1c80488853d86ab9d6decfe30d8930f_2" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_4" [label="4: BinaryOperatorStmt: Assign \n *&a:int=3 [line 55, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_4" -> "g2.e1c80488853d86ab9d6decfe30d8930f_3" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_5" [label="5: Skip GotoLabel_exit_step \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_5" -> "g2.e1c80488853d86ab9d6decfe30d8930f_4" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_6" [label="6: Return Stmt \n *&return:int=2 [line 52, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_6" -> "g2.e1c80488853d86ab9d6decfe30d8930f_2" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_7" [label="7: BinaryOperatorStmt: Assign \n *&a:int=2 [line 51, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_7" -> "g2.e1c80488853d86ab9d6decfe30d8930f_6" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_8" [label="8: Skip GotoLabel_stepA \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_8" -> "g2.e1c80488853d86ab9d6decfe30d8930f_7" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_9" [label="9: Return Stmt \n *&return:int=0 [line 48, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_9" -> "g2.e1c80488853d86ab9d6decfe30d8930f_2" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_10" [label="10: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_10" -> "g2.e1c80488853d86ab9d6decfe30d8930f_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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_11" [label="11: BinaryOperatorStmt: GT \n n$2=_fun_getValue() [line 46, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_11" -> "g2.e1c80488853d86ab9d6decfe30d8930f_12" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_11" -> "g2.e1c80488853d86ab9d6decfe30d8930f_13" ;
|
[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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_12" [label="12: Prune (true branch, if) \n PRUNE((n$2 > 1), true); [line 46, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_12" -> "g2.e1c80488853d86ab9d6decfe30d8930f_14" ;
|
[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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_13" [label="13: Prune (false branch, if) \n PRUNE(!(n$2 > 1), false); [line 46, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_13" -> "g2.e1c80488853d86ab9d6decfe30d8930f_10" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_14" [label="14: Skip GotoLabel_stepB \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_14" -> "g2.e1c80488853d86ab9d6decfe30d8930f_23" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_15" [label="15: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_15" -> "g2.e1c80488853d86ab9d6decfe30d8930f_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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_16" [label="16: Call _fun_getValue \n n$6=_fun_getValue() [line 44, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_16" -> "g2.e1c80488853d86ab9d6decfe30d8930f_17" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_16" -> "g2.e1c80488853d86ab9d6decfe30d8930f_18" ;
|
[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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_17" [label="17: Prune (true branch, if) \n PRUNE(!n$6, true); [line 44, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_17" -> "g2.e1c80488853d86ab9d6decfe30d8930f_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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_18" [label="18: Prune (false branch, if) \n PRUNE(n$6, false); [line 44, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_18" -> "g2.e1c80488853d86ab9d6decfe30d8930f_15" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_19" [label="19: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_19" -> "g2.e1c80488853d86ab9d6decfe30d8930f_16" ;
|
[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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_20" [label="20: Call _fun_getValue \n n$10=_fun_getValue() [line 42, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_20" -> "g2.e1c80488853d86ab9d6decfe30d8930f_21" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_20" -> "g2.e1c80488853d86ab9d6decfe30d8930f_22" ;
|
[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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_21" [label="21: Prune (true branch, if) \n PRUNE(!n$10, true); [line 42, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_21" -> "g2.e1c80488853d86ab9d6decfe30d8930f_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
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_22" [label="22: Prune (false branch, if) \n PRUNE(n$10, false); [line 42, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_22" -> "g2.e1c80488853d86ab9d6decfe30d8930f_19" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_23" [label="23: BinaryOperatorStmt: Assign \n *&a:int=1 [line 40, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_23" -> "g2.e1c80488853d86ab9d6decfe30d8930f_20" ;
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_24" [label="24: DeclStmt \n *&a:int=0 [line 38, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g2.e1c80488853d86ab9d6decfe30d8930f_24" -> "g2.e1c80488853d86ab9d6decfe30d8930f_14" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_1" [label="1: Start g3\nFormals: \nLocals: a:int \n DECLARE_LOCALS(&return,&a); [line 59, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_1" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_15" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_2" [label="2: Exit g3 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_3" [label="3: Return Stmt \n *&return:int=1 [line 78, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_3" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_2" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_4" [label="4: Call _fun_printf \n n$0=_fun_printf(\"exit\\n\":char const *) [line 77, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_4" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_3" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_5" [label="5: Skip GotoLabel_exit_step \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_5" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_6" [label="6: Call _fun_printf \n n$2=_fun_printf(\"A\\n\":char const *) [line 74, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_6" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_5" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_7" [label="7: DeclStmt \n *&a:int=2 [line 73, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_7" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_6" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_8" [label="8: Skip GotoLabel_stepA \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_8" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_7" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_9" [label="9: Return Stmt \n *&return:int=0 [line 70, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_9" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_10" [label="10: Call _fun_printf \n n$4=_fun_printf(\"g3\\n\":char const *) [line 69, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_10" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_9" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_11" [label="11: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_11" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_12" [label="12: BinaryOperatorStmt: GT \n n$5=_fun_getValue() [line 67, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_12" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_13" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_12" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_14" ;
|
[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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_13" [label="13: Prune (true branch, if) \n PRUNE((n$5 > 1), true); [line 67, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_13" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_15" ;
|
[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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_14" [label="14: Prune (false branch, if) \n PRUNE(!(n$5 > 1), false); [line 67, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_14" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_11" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_15" [label="15: Skip GotoLabel_stepB \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_15" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_24" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_16" [label="16: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_16" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_12" ;
|
[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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_17" [label="17: Call _fun_getValue \n n$9=_fun_getValue() [line 65, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_17" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_18" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_17" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_19" ;
|
[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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_18" [label="18: Prune (true branch, if) \n PRUNE(!n$9, true); [line 65, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_18" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_19" [label="19: Prune (false branch, if) \n PRUNE(n$9, false); [line 65, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_19" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_16" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_20" [label="20: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_20" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_17" ;
|
[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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_21" [label="21: Call _fun_getValue \n n$13=_fun_getValue() [line 63, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_21" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_22" ;
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_21" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_23" ;
|
[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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_22" [label="22: Prune (true branch, if) \n PRUNE(!n$13, true); [line 63, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_22" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_23" [label="23: Prune (false branch, if) \n PRUNE(n$13, false); [line 63, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_23" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_20" ;
|
[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
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_24" [label="24: Call _fun_printf \n n$17=_fun_printf(\"B\\n\":char const *) [line 61, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g3.8a9fd7dfda802921fdc4079f9a528ce8_24" -> "g3.8a9fd7dfda802921fdc4079f9a528ce8_21" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_1" [label="1: Start g4\nFormals: \nLocals: a:int \n DECLARE_LOCALS(&return,&a); [line 81, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_1" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_14" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_2" [label="2: Exit g4 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_3" [label="3: Return Stmt \n *&return:int=1 [line 99, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_3" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_2" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_4" [label="4: Call _fun_printf \n n$0=_fun_printf(\"exit\\n\":char const *) [line 98, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_4" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_3" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_5" [label="5: Skip GotoLabel_exit_step \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_5" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_6" [label="6: Call _fun_printf \n n$2=_fun_printf(\"A\\n\":char const *) [line 95, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_6" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_5" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_7" [label="7: DeclStmt \n *&a:int=2 [line 94, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_7" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_6" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_8" [label="8: Skip GotoLabel_stepA \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_8" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_9" [label="9: Call _fun_printf \n n$4=_fun_printf(\"g4\\n\":char const *) [line 91, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_9" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_8" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_10" [label="10: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_10" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_11" [label="11: BinaryOperatorStmt: GT \n n$5=_fun_getValue() [line 89, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_11" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_12" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_11" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_13" ;
|
[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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_12" [label="12: Prune (true branch, if) \n PRUNE((n$5 > 1), true); [line 89, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_12" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_14" ;
|
[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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_13" [label="13: Prune (false branch, if) \n PRUNE(!(n$5 > 1), false); [line 89, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_13" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_10" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_14" [label="14: Skip GotoLabel_stepB \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_14" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_23" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_15" [label="15: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_15" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_16" [label="16: Call _fun_getValue \n n$9=_fun_getValue() [line 87, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_16" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_17" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_16" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_18" ;
|
[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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_17" [label="17: Prune (true branch, if) \n PRUNE(!n$9, true); [line 87, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_17" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_18" [label="18: Prune (false branch, if) \n PRUNE(n$9, false); [line 87, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_18" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_15" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_19" [label="19: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_19" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_16" ;
|
[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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_20" [label="20: Call _fun_getValue \n n$13=_fun_getValue() [line 85, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_20" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_21" ;
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_20" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_22" ;
|
[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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_21" [label="21: Prune (true branch, if) \n PRUNE(!n$13, true); [line 85, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_21" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_22" [label="22: Prune (false branch, if) \n PRUNE(n$13, false); [line 85, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_22" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_19" ;
|
[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
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_23" [label="23: Call _fun_printf \n n$17=_fun_printf(\"B\\n\":char const *) [line 83, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g4.b0b5c8f28ad7834e70a958a8882fa59a_23" -> "g4.b0b5c8f28ad7834e70a958a8882fa59a_20" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_1" [label="1: Start g5\nFormals: \nLocals: a:int \n DECLARE_LOCALS(&return,&a); [line 102, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_1" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_13" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_2" [label="2: Exit g5 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_3" [label="3: Skip GotoLabel_stepA \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_3" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_4" [label="4: Call _fun_printf \n n$1=_fun_printf(\"exit\\n\":char const *) [line 120, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_4" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_3" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_5" [label="5: Skip GotoLabel_exit_step \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_5" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_4" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_6" [label="6: Return Stmt \n *&return:int=1 [line 117, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_6" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_7" [label="7: Call _fun_printf \n n$3=_fun_printf(\"A\\n\":char const *) [line 116, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_7" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_6" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_8" [label="8: DeclStmt \n *&a:int=2 [line 115, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_8" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_7" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_9" [label="9: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_9" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_10" [label="10: BinaryOperatorStmt: GT \n n$6=_fun_getValue() [line 110, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_10" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_11" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_10" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_12" ;
|
[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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_11" [label="11: Prune (true branch, if) \n PRUNE((n$6 > 1), true); [line 110, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_11" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_13" ;
|
[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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_12" [label="12: Prune (false branch, if) \n PRUNE(!(n$6 > 1), false); [line 110, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_12" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_9" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_13" [label="13: Skip GotoLabel_stepB \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_13" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_22" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_14" [label="14: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_14" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_15" [label="15: Call _fun_getValue \n n$10=_fun_getValue() [line 108, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_15" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_16" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_15" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_17" ;
|
[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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_16" [label="16: Prune (true branch, if) \n PRUNE(!n$10, true); [line 108, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_16" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_17" [label="17: Prune (false branch, if) \n PRUNE(n$10, false); [line 108, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_17" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_14" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_18" [label="18: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_18" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_15" ;
|
[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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_19" [label="19: Call _fun_getValue \n n$14=_fun_getValue() [line 106, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_19" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_20" ;
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_19" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_21" ;
|
[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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_20" [label="20: Prune (true branch, if) \n PRUNE(!n$14, true); [line 106, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_20" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_21" [label="21: Prune (false branch, if) \n PRUNE(n$14, false); [line 106, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_21" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_18" ;
|
[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
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_22" [label="22: Call _fun_printf \n n$18=_fun_printf(\"B\\n\":char const *) [line 104, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g5.37c965a8d6d7bec292c7b11ff315d9ea_22" -> "g5.37c965a8d6d7bec292c7b11ff315d9ea_19" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_1" [label="1: Start g6\nFormals: \nLocals: a:int \n DECLARE_LOCALS(&return,&a); [line 124, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_1" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_13" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_2" [label="2: Exit g6 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_3" [label="3: Skip GotoLabel_stepA \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_3" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_4" [label="4: Call _fun_printf \n n$1=_fun_printf(\"exit\\n\":char const *) [line 142, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_4" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_3" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_5" [label="5: Skip GotoLabel_exit_step \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_5" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_4" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_6" [label="6: Return Stmt \n *&return:int=1 [line 140, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_6" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_7" [label="7: Call _fun_printf \n n$3=_fun_printf(\"A\\n\":char const *) [line 138, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_7" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_6" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_8" [label="8: DeclStmt \n *&a:int=2 [line 137, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_8" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_7" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_9" [label="9: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_9" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_10" [label="10: BinaryOperatorStmt: GT \n n$6=_fun_getValue() [line 132, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_10" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_11" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_10" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_12" ;
|
[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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_11" [label="11: Prune (true branch, if) \n PRUNE((n$6 > 1), true); [line 132, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_11" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_13" ;
|
[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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_12" [label="12: Prune (false branch, if) \n PRUNE(!(n$6 > 1), false); [line 132, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_12" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_9" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_13" [label="13: Skip GotoLabel_stepB \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_13" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_22" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_14" [label="14: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_14" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_15" [label="15: Call _fun_getValue \n n$10=_fun_getValue() [line 130, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_15" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_16" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_15" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_17" ;
|
[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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_16" [label="16: Prune (true branch, if) \n PRUNE(!n$10, true); [line 130, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_16" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_17" [label="17: Prune (false branch, if) \n PRUNE(n$10, false); [line 130, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_17" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_14" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_18" [label="18: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_18" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_15" ;
|
[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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_19" [label="19: Call _fun_getValue \n n$14=_fun_getValue() [line 128, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_19" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_20" ;
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_19" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_21" ;
|
[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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_20" [label="20: Prune (true branch, if) \n PRUNE(!n$14, true); [line 128, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_20" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_21" [label="21: Prune (false branch, if) \n PRUNE(n$14, false); [line 128, column 8]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_21" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_18" ;
|
[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
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_22" [label="22: Call _fun_printf \n n$18=_fun_printf(\"B\\n\":char const *) [line 126, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g6.4a4314ef967aad20a9e7c423bc16e39c_22" -> "g6.4a4314ef967aad20a9e7c423bc16e39c_19" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_1" [label="1: Start g7\nFormals: \nLocals: v:int k:int j:int i:int \n DECLARE_LOCALS(&return,&v,&k,&j,&i); [line 146, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_1" -> "g7.727bb92f57c3951d11695a52c92c2b0c_29" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_2" [label="2: Exit g7 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_3" [label="3: Return Stmt \n *&return:int=2 [line 166, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_3" -> "g7.727bb92f57c3951d11695a52c92c2b0c_2" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_4" [label="4: Call _fun_printf \n n$0=_fun_printf(\"terminating!\\n\":char const *) [line 165, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_4" -> "g7.727bb92f57c3951d11695a52c92c2b0c_3" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_5" [label="5: Skip GotoLabel_terminate \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_5" -> "g7.727bb92f57c3951d11695a52c92c2b0c_4" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_6" [label="6: Skip GotoLabel_print \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_6" -> "g7.727bb92f57c3951d11695a52c92c2b0c_25" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_7" [label="7: Call _fun_printf \n n$3=_fun_printf(\"out!\\n\":char const *) [line 162, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_7" -> "g7.727bb92f57c3951d11695a52c92c2b0c_6" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_8" [label="8: Skip GotoLabel_out \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_8" -> "g7.727bb92f57c3951d11695a52c92c2b0c_7" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_9" [label="9: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_9" -> "g7.727bb92f57c3951d11695a52c92c2b0c_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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_10" [label="10: BinaryOperatorStmt: LT \n n$5=*&i:int [line 148, column 10]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_10" -> "g7.727bb92f57c3951d11695a52c92c2b0c_11" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_10" -> "g7.727bb92f57c3951d11695a52c92c2b0c_12" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_11" [label="11: Prune (true branch, while) \n PRUNE((n$5 < 10), true); [line 148, column 10]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_11" -> "g7.727bb92f57c3951d11695a52c92c2b0c_13" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_12" [label="12: Prune (false branch, while) \n PRUNE(!(n$5 < 10), false); [line 148, column 10]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_12" -> "g7.727bb92f57c3951d11695a52c92c2b0c_8" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_13" [label="13: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_13" -> "g7.727bb92f57c3951d11695a52c92c2b0c_14" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_14" [label="14: BinaryOperatorStmt: LT \n n$6=*&j:int [line 149, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_14" -> "g7.727bb92f57c3951d11695a52c92c2b0c_15" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_14" -> "g7.727bb92f57c3951d11695a52c92c2b0c_16" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_15" [label="15: Prune (true branch, while) \n PRUNE((n$6 < 10), true); [line 149, column 12]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_15" -> "g7.727bb92f57c3951d11695a52c92c2b0c_17" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_16" [label="16: Prune (false branch, while) \n PRUNE(!(n$6 < 10), false); [line 149, column 12]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_16" -> "g7.727bb92f57c3951d11695a52c92c2b0c_9" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_17" [label="17: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_17" -> "g7.727bb92f57c3951d11695a52c92c2b0c_18" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_18" [label="18: BinaryOperatorStmt: LT \n n$7=*&k:int [line 150, column 14]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_18" -> "g7.727bb92f57c3951d11695a52c92c2b0c_19" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_18" -> "g7.727bb92f57c3951d11695a52c92c2b0c_20" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_19" [label="19: Prune (true branch, while) \n PRUNE((n$7 < 10), true); [line 150, column 14]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_19" -> "g7.727bb92f57c3951d11695a52c92c2b0c_26" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_20" [label="20: Prune (false branch, while) \n PRUNE(!(n$7 < 10), false); [line 150, column 14]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_20" -> "g7.727bb92f57c3951d11695a52c92c2b0c_13" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_21" [label="21: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_21" -> "g7.727bb92f57c3951d11695a52c92c2b0c_17" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_22" [label="22: BinaryOperatorStmt: GE \n n$8=*&v:int [line 152, column 13]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_22" -> "g7.727bb92f57c3951d11695a52c92c2b0c_23" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_22" -> "g7.727bb92f57c3951d11695a52c92c2b0c_24" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_23" [label="23: Prune (true branch, if) \n PRUNE((n$8 >= 15), true); [line 152, column 13]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_23" -> "g7.727bb92f57c3951d11695a52c92c2b0c_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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_24" [label="24: Prune (false branch, if) \n PRUNE(!(n$8 >= 15), false); [line 152, column 13]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_24" -> "g7.727bb92f57c3951d11695a52c92c2b0c_21" ;
|
[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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_25" [label="25: Call _fun_printf \n n$10=_fun_printf(\"wow\\n\":char const *) [line 155, column 11]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_25" -> "g7.727bb92f57c3951d11695a52c92c2b0c_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
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_26" [label="26: DeclStmt \n n$15=*&i:int [line 151, column 17]\n n$16=*&j:int [line 151, column 21]\n n$17=*&k:int [line 151, column 25]\n *&v:int=((n$15 + n$16) + n$17) [line 151, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_26" -> "g7.727bb92f57c3951d11695a52c92c2b0c_22" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_27" [label="27: DeclStmt \n *&k:int=0 [line 147, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_27" -> "g7.727bb92f57c3951d11695a52c92c2b0c_9" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_28" [label="28: DeclStmt \n *&j:int=0 [line 147, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_28" -> "g7.727bb92f57c3951d11695a52c92c2b0c_27" ;
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_29" [label="29: DeclStmt \n *&i:int=0 [line 147, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g7.727bb92f57c3951d11695a52c92c2b0c_29" -> "g7.727bb92f57c3951d11695a52c92c2b0c_28" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_1" [label="1: Start g8\nFormals: q:int\nLocals: v:int k:int j:int i:int \n DECLARE_LOCALS(&return,&v,&k,&j,&i); [line 169, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_1" -> "g8.c98b82371573afc08575815d90f5eac4_32" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_2" [label="2: Exit g8 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_3" [label="3: Return Stmt \n *&return:int=2 [line 189, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_3" -> "g8.c98b82371573afc08575815d90f5eac4_2" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_4" [label="4: Call _fun_printf \n n$0=_fun_printf(\"terminating!\\n\":char const *) [line 188, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_4" -> "g8.c98b82371573afc08575815d90f5eac4_3" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_5" [label="5: Skip GotoLabel_terminate \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_5" -> "g8.c98b82371573afc08575815d90f5eac4_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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_6" [label="6: Call _fun_printf \n n$2=_fun_printf(\"out!\\n\":char const *) [line 186, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_6" -> "g8.c98b82371573afc08575815d90f5eac4_5" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_7" [label="7: Skip GotoLabel_out \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_7" -> "g8.c98b82371573afc08575815d90f5eac4_6" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_8" [label="8: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_8" -> "g8.c98b82371573afc08575815d90f5eac4_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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_9" [label="9: BinaryOperatorStmt: LT \n n$4=*&i:int [line 173, column 10]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_9" -> "g8.c98b82371573afc08575815d90f5eac4_10" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_9" -> "g8.c98b82371573afc08575815d90f5eac4_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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_10" [label="10: Prune (true branch, while) \n PRUNE((n$4 < 10), true); [line 173, column 10]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_10" -> "g8.c98b82371573afc08575815d90f5eac4_12" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_11" [label="11: Prune (false branch, while) \n PRUNE(!(n$4 < 10), false); [line 173, column 10]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_11" -> "g8.c98b82371573afc08575815d90f5eac4_7" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_12" [label="12: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_12" -> "g8.c98b82371573afc08575815d90f5eac4_13" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_13" [label="13: BinaryOperatorStmt: LT \n n$5=*&j:int [line 174, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_13" -> "g8.c98b82371573afc08575815d90f5eac4_14" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_13" -> "g8.c98b82371573afc08575815d90f5eac4_15" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_14" [label="14: Prune (true branch, while) \n PRUNE((n$5 < 10), true); [line 174, column 12]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_14" -> "g8.c98b82371573afc08575815d90f5eac4_16" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_15" [label="15: Prune (false branch, while) \n PRUNE(!(n$5 < 10), false); [line 174, column 12]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_15" -> "g8.c98b82371573afc08575815d90f5eac4_8" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_16" [label="16: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_16" -> "g8.c98b82371573afc08575815d90f5eac4_17" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_17" [label="17: BinaryOperatorStmt: LT \n n$6=*&k:int [line 175, column 14]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_17" -> "g8.c98b82371573afc08575815d90f5eac4_18" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_17" -> "g8.c98b82371573afc08575815d90f5eac4_19" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_18" [label="18: Prune (true branch, while) \n PRUNE((n$6 < 10), true); [line 175, column 14]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_18" -> "g8.c98b82371573afc08575815d90f5eac4_26" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_19" [label="19: Prune (false branch, while) \n PRUNE(!(n$6 < 10), false); [line 175, column 14]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_19" -> "g8.c98b82371573afc08575815d90f5eac4_12" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_20" [label="20: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_20" -> "g8.c98b82371573afc08575815d90f5eac4_16" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_21" [label="21: BinaryOperatorStmt: GE \n n$7=*&v:int [line 177, column 13]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_21" -> "g8.c98b82371573afc08575815d90f5eac4_22" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_21" -> "g8.c98b82371573afc08575815d90f5eac4_23" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_22" [label="22: Prune (true branch, if) \n PRUNE((n$7 >= 15), true); [line 177, column 13]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_22" -> "g8.c98b82371573afc08575815d90f5eac4_25" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_23" [label="23: Prune (false branch, if) \n PRUNE(!(n$7 >= 15), false); [line 177, column 13]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_23" -> "g8.c98b82371573afc08575815d90f5eac4_20" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_24" [label="24: Call _fun_printf \n n$8=_fun_printf(\"wow\\n\":char const *) [line 179, column 11]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_24" -> "g8.c98b82371573afc08575815d90f5eac4_20" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_25" [label="25: Skip GotoLabel_print \n " color="gray"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_25" -> "g8.c98b82371573afc08575815d90f5eac4_24" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_26" [label="26: DeclStmt \n n$12=*&i:int [line 176, column 17]\n n$13=*&j:int [line 176, column 21]\n n$14=*&k:int [line 176, column 25]\n *&v:int=((n$12 + n$13) + n$14) [line 176, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_26" -> "g8.c98b82371573afc08575815d90f5eac4_21" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_27" [label="27: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_27" -> "g8.c98b82371573afc08575815d90f5eac4_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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_28" [label="28: Prune (true branch, if) \n n$18=*&q:int [line 171, column 7]\n PRUNE(n$18, true); [line 171, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_28" -> "g8.c98b82371573afc08575815d90f5eac4_25" ;
|
[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
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_29" [label="29: Prune (false branch, if) \n n$18=*&q:int [line 171, column 7]\n PRUNE(!n$18, false); [line 171, column 7]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_29" -> "g8.c98b82371573afc08575815d90f5eac4_27" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_30" [label="30: DeclStmt \n *&k:int=0 [line 170, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_30" -> "g8.c98b82371573afc08575815d90f5eac4_28" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_30" -> "g8.c98b82371573afc08575815d90f5eac4_29" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_31" [label="31: DeclStmt \n *&j:int=0 [line 170, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_31" -> "g8.c98b82371573afc08575815d90f5eac4_30" ;
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_32" [label="32: DeclStmt \n *&i:int=0 [line 170, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"g8.c98b82371573afc08575815d90f5eac4_32" -> "g8.c98b82371573afc08575815d90f5eac4_31" ;
|
|
|
|
|
"getValue.faa0c7b1433b0c97fcdc15fa47c8180f_1" [label="1: Start getValue\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 12, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"getValue.faa0c7b1433b0c97fcdc15fa47c8180f_1" -> "getValue.faa0c7b1433b0c97fcdc15fa47c8180f_3" ;
|
|
|
|
|
"getValue.faa0c7b1433b0c97fcdc15fa47c8180f_2" [label="2: Exit getValue \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"getValue.faa0c7b1433b0c97fcdc15fa47c8180f_3" [label="3: Return Stmt \n *&return:int=2 [line 12, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"getValue.faa0c7b1433b0c97fcdc15fa47c8180f_3" -> "getValue.faa0c7b1433b0c97fcdc15fa47c8180f_2" ;
|
|
|
|
|
}
|
