|
|
|
/* @generated */
|
|
|
|
digraph cfg {
|
|
|
|
"fun_p#7468829763884786220.ff1d58f26970dcc8ee3c2a153c5a5b85_1" [label="1: Start fun_p\nFormals: p:int*\nLocals: \n DECLARE_LOCALS(&return); [line 10, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_p#7468829763884786220.ff1d58f26970dcc8ee3c2a153c5a5b85_1" -> "fun_p#7468829763884786220.ff1d58f26970dcc8ee3c2a153c5a5b85_3" ;
|
|
|
|
"fun_p#7468829763884786220.ff1d58f26970dcc8ee3c2a153c5a5b85_2" [label="2: Exit fun_p \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_p#7468829763884786220.ff1d58f26970dcc8ee3c2a153c5a5b85_3" [label="3: Return Stmt \n n$0=*&p:int* [line 10, column 29]\n n$1=*n$0:int [line 10, column 28]\n *&return:int=n$1 [line 10, column 21]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_p#7468829763884786220.ff1d58f26970dcc8ee3c2a153c5a5b85_3" -> "fun_p#7468829763884786220.ff1d58f26970dcc8ee3c2a153c5a5b85_2" ;
|
|
|
|
"fun_r#8688550998084520100.a539308a01e8443f65be5d44c29a73f6_1" [label="1: Start fun_r\nFormals: p:int&\nLocals: \n DECLARE_LOCALS(&return); [line 12, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_r#8688550998084520100.a539308a01e8443f65be5d44c29a73f6_1" -> "fun_r#8688550998084520100.a539308a01e8443f65be5d44c29a73f6_3" ;
|
|
|
|
"fun_r#8688550998084520100.a539308a01e8443f65be5d44c29a73f6_2" [label="2: Exit fun_r \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_r#8688550998084520100.a539308a01e8443f65be5d44c29a73f6_3" [label="3: Return Stmt \n n$0=*&p:int& [line 12, column 28]\n n$1=*n$0:int [line 12, column 28]\n *&return:int=n$1 [line 12, column 21]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_r#8688550998084520100.a539308a01e8443f65be5d44c29a73f6_3" -> "fun_r#8688550998084520100.a539308a01e8443f65be5d44c29a73f6_2" ;
|
|
|
|
"fun_v#125358748374922080.2b082c989a86eb6a918b15eb596c685a_1" [label="1: Start fun_v\nFormals: p:int\nLocals: \n DECLARE_LOCALS(&return); [line 11, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_v#125358748374922080.2b082c989a86eb6a918b15eb596c685a_1" -> "fun_v#125358748374922080.2b082c989a86eb6a918b15eb596c685a_3" ;
|
|
|
|
"fun_v#125358748374922080.2b082c989a86eb6a918b15eb596c685a_2" [label="2: Exit fun_v \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_v#125358748374922080.2b082c989a86eb6a918b15eb596c685a_3" [label="3: Return Stmt \n n$0=*&p:int [line 11, column 27]\n *&return:int=n$0 [line 11, column 20]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"fun_v#125358748374922080.2b082c989a86eb6a918b15eb596c685a_3" -> "fun_v#125358748374922080.2b082c989a86eb6a918b15eb596c685a_2" ;
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_1" [label="1: Start unbox_ptr\nFormals: \nLocals: p:int* a:int \n DECLARE_LOCALS(&return,&p,&a); [line 27, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_1" -> "unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_7" ;
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_2" [label="2: Exit unbox_ptr \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
[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
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_3" [label="3: Call _fun_fun_r \n n$1=*&p:int* [line 33, column 10]\n n$2=_fun_fun_r(n$1:int&) [line 33, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_3" -> "unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_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
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_4" [label="4: Call _fun_fun_v \n n$3=*&p:int* [line 32, column 10]\n n$4=*n$3:int [line 32, column 9]\n n$5=_fun_fun_v(n$4:int) [line 32, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_4" -> "unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_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
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_5" [label="5: Call _fun_fun_p \n n$6=*&p:int* [line 31, column 9]\n n$7=_fun_fun_p(n$6:int*) [line 31, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_5" -> "unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_4" ;
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_6" [label="6: DeclStmt \n *&p:int*=&a [line 29, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_6" -> "unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_5" ;
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_7" [label="7: DeclStmt \n *&a:int=3 [line 28, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_7" -> "unbox_ptr#3550280956167916174.75d50cc2e2dfffd1cc23613b01fc878b_6" ;
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_1" [label="1: Start unbox_ref\nFormals: \nLocals: r:int& a:int \n DECLARE_LOCALS(&return,&r,&a); [line 17, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_1" -> "unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_7" ;
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_2" [label="2: Exit unbox_ref \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
[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
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_3" [label="3: Call _fun_fun_r \n n$1=*&r:int& [line 23, column 9]\n n$2=_fun_fun_r(n$1:int&) [line 23, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_3" -> "unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_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
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_4" [label="4: Call _fun_fun_v \n n$3=*&r:int& [line 22, column 9]\n n$4=*n$3:int [line 22, column 9]\n n$5=_fun_fun_v(n$4:int) [line 22, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_4" -> "unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_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
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_5" [label="5: Call _fun_fun_p \n n$6=*&r:int& [line 21, column 10]\n n$7=_fun_fun_p(n$6:int*) [line 21, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_5" -> "unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_4" ;
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_6" [label="6: DeclStmt \n *&r:int&=&a [line 19, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_6" -> "unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_5" ;
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_7" [label="7: DeclStmt \n *&a:int=3 [line 18, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
"unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_7" -> "unbox_ref#9977470601320200599.91094dce9e5b43dc4c89abcbc69b2c70_6" ;
|
|
|
|
}
|