|
|
|
|
/* @generated */
|
|
|
|
|
digraph cfg {
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_1" [label="1: Start main\nFormals: \nLocals: rect2:foo::Rectangle rect1:bar::Rectangle x:foo::my_record j:double i:int \n DECLARE_LOCALS(&return,&rect2,&rect1,&x,&j,&i); [line 41, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_1" -> "main.fad58de7366495db4650cfefac2fcd61_12" ;
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_2" [label="2: Exit main \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_3" [label="3: Return Stmt \n *&return:int=0 [line 58, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_3" -> "main.fad58de7366495db4650cfefac2fcd61_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
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_4" [label="4: BinaryOperatorStmt: Assign \n n$1=*&#GB<codetoanalyze/cpp/shared/namespace/namespace.cpp>$bar::pi:double [line 57, column 7]\n *&j:double=n$1 [line 57, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_4" -> "main.fad58de7366495db4650cfefac2fcd61_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
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_5" [label="5: BinaryOperatorStmt: Assign \n n$2=_fun_bar::value() [line 56, column 7]\n *&i:int=n$2 [line 56, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_5" -> "main.fad58de7366495db4650cfefac2fcd61_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
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_6" [label="6: BinaryOperatorStmt: Assign \n n$3=_fun_foo::value() [line 55, column 7]\n *&i:int=n$3 [line 55, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_6" -> "main.fad58de7366495db4650cfefac2fcd61_5" ;
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_7" [label="7: BinaryOperatorStmt: Assign \n *&x.a:int=10 [line 54, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_7" -> "main.fad58de7366495db4650cfefac2fcd61_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
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_8" [label="8: Call _fun_foo::Rectangle_set_values \n _=*&rect2:foo::Rectangle [line 52, column 3]\n n$5=_fun_foo::Rectangle_set_values(&rect2:foo::Rectangle&,7:int,10:int) [line 52, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_8" -> "main.fad58de7366495db4650cfefac2fcd61_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
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_9" [label="9: DeclStmt \n n$6=_fun_foo::Rectangle_Rectangle(&rect2:foo::Rectangle*) [line 51, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_9" -> "main.fad58de7366495db4650cfefac2fcd61_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
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_10" [label="10: Call _fun_bar::Rectangle_set_values \n _=*&rect1:bar::Rectangle [line 49, column 3]\n n$8=_fun_bar::Rectangle_set_values(&rect1:bar::Rectangle&,3:int,4:int) [line 49, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_10" -> "main.fad58de7366495db4650cfefac2fcd61_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
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_11" [label="11: DeclStmt \n n$9=_fun_bar::Rectangle_Rectangle(&rect1:bar::Rectangle*) [line 48, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_11" -> "main.fad58de7366495db4650cfefac2fcd61_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
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_12" [label="12: DeclStmt \n n$10=_fun_foo::my_record_(&x:foo::my_record*) [line 46, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"main.fad58de7366495db4650cfefac2fcd61_12" -> "main.fad58de7366495db4650cfefac2fcd61_11" ;
|
|
|
|
|
"pi#__infer_globals_initializer_bar.1155d696836634e07d40a8f71831e209_1" [label="1: Start __infer_globals_initializer_bar::pi\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 29, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"pi#__infer_globals_initializer_bar.1155d696836634e07d40a8f71831e209_1" -> "pi#__infer_globals_initializer_bar.1155d696836634e07d40a8f71831e209_3" ;
|
|
|
|
|
"pi#__infer_globals_initializer_bar.1155d696836634e07d40a8f71831e209_2" [label="2: Exit __infer_globals_initializer_bar::pi \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"pi#__infer_globals_initializer_bar.1155d696836634e07d40a8f71831e209_3" [label="3: DeclStmt \n *&#GB<codetoanalyze/cpp/shared/namespace/namespace.cpp>$bar::pi:double=3.1416 [line 29, column 1]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"pi#__infer_globals_initializer_bar.1155d696836634e07d40a8f71831e209_3" -> "pi#__infer_globals_initializer_bar.1155d696836634e07d40a8f71831e209_2" ;
|
|
|
|
|
"rect#__infer_globals_initializer_bar.4a1fbff7dd04d46c33088cc2bed92914_1" [label="1: Start __infer_globals_initializer_bar::rect\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 32, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect#__infer_globals_initializer_bar.4a1fbff7dd04d46c33088cc2bed92914_1" -> "rect#__infer_globals_initializer_bar.4a1fbff7dd04d46c33088cc2bed92914_3" ;
|
|
|
|
|
"rect#__infer_globals_initializer_bar.4a1fbff7dd04d46c33088cc2bed92914_2" [label="2: Exit __infer_globals_initializer_bar::rect \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect#__infer_globals_initializer_bar.4a1fbff7dd04d46c33088cc2bed92914_3" [label="3: DeclStmt \n n$0=_fun_bar::Rectangle_Rectangle(&#GB<codetoanalyze/cpp/shared/namespace/namespace.cpp|!pod>$bar::rect:bar::Rectangle*) [line 38, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect#__infer_globals_initializer_bar.4a1fbff7dd04d46c33088cc2bed92914_3" -> "rect#__infer_globals_initializer_bar.4a1fbff7dd04d46c33088cc2bed92914_2" ;
|
|
|
|
|
"value#bar#16302148298864778751.e55afab5e7523c08687d7e6558d5dad5_1" [label="1: Start bar::value\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 30, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"value#bar#16302148298864778751.e55afab5e7523c08687d7e6558d5dad5_1" -> "value#bar#16302148298864778751.e55afab5e7523c08687d7e6558d5dad5_3" ;
|
|
|
|
|
"value#bar#16302148298864778751.e55afab5e7523c08687d7e6558d5dad5_2" [label="2: Exit bar::value \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"value#bar#16302148298864778751.e55afab5e7523c08687d7e6558d5dad5_3" [label="3: Return Stmt \n n$0=*&#GB<codetoanalyze/cpp/shared/namespace/namespace.cpp>$bar::pi:double [line 30, column 29]\n *&return:double=(2 * n$0) [line 30, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"value#bar#16302148298864778751.e55afab5e7523c08687d7e6558d5dad5_3" -> "value#bar#16302148298864778751.e55afab5e7523c08687d7e6558d5dad5_2" ;
|
|
|
|
|
"value#foo#118977410660901546.9623db3632a56e3cb17951602d147a29_1" [label="1: Start foo::value\nFormals: \nLocals: \n DECLARE_LOCALS(&return); [line 17, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"value#foo#118977410660901546.9623db3632a56e3cb17951602d147a29_1" -> "value#foo#118977410660901546.9623db3632a56e3cb17951602d147a29_3" ;
|
|
|
|
|
"value#foo#118977410660901546.9623db3632a56e3cb17951602d147a29_2" [label="2: Exit foo::value \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"value#foo#118977410660901546.9623db3632a56e3cb17951602d147a29_3" [label="3: Return Stmt \n *&return:int=5 [line 17, column 15]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"value#foo#118977410660901546.9623db3632a56e3cb17951602d147a29_3" -> "value#foo#118977410660901546.9623db3632a56e3cb17951602d147a29_2" ;
|
|
|
|
|
"#my_record#foo#{787932800218645857}.139a63942c62b7df5ae81187e8434e41_1" [label="1: Start foo::my_record_\nFormals: this:foo::my_record*\nLocals: \n DECLARE_LOCALS(&return); [line 13, column 9]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"#my_record#foo#{787932800218645857}.139a63942c62b7df5ae81187e8434e41_1" -> "#my_record#foo#{787932800218645857}.139a63942c62b7df5ae81187e8434e41_2" ;
|
|
|
|
|
"#my_record#foo#{787932800218645857}.139a63942c62b7df5ae81187e8434e41_2" [label="2: Exit foo::my_record_ \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Rectangle#Rectangle#bar#{16076319501091404979}.cb85c0acc359c05c70c9c64fe7f882ea_1" [label="1: Start bar::Rectangle_Rectangle\nFormals: this:bar::Rectangle*\nLocals: \n DECLARE_LOCALS(&return); [line 32, column 7]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Rectangle#Rectangle#bar#{16076319501091404979}.cb85c0acc359c05c70c9c64fe7f882ea_1" -> "Rectangle#Rectangle#bar#{16076319501091404979}.cb85c0acc359c05c70c9c64fe7f882ea_2" ;
|
|
|
|
|
"Rectangle#Rectangle#bar#{16076319501091404979}.cb85c0acc359c05c70c9c64fe7f882ea_2" [label="2: Exit bar::Rectangle_Rectangle \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Rectangle#Rectangle#foo#{8572033467385947510}.aa3c63f2774d4a30536ec4553aa11554_1" [label="1: Start foo::Rectangle_Rectangle\nFormals: this:foo::Rectangle*\nLocals: \n DECLARE_LOCALS(&return); [line 19, column 7]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Rectangle#Rectangle#foo#{8572033467385947510}.aa3c63f2774d4a30536ec4553aa11554_1" -> "Rectangle#Rectangle#foo#{8572033467385947510}.aa3c63f2774d4a30536ec4553aa11554_2" ;
|
|
|
|
|
"Rectangle#Rectangle#foo#{8572033467385947510}.aa3c63f2774d4a30536ec4553aa11554_2" [label="2: Exit foo::Rectangle_Rectangle \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
}
|
