|
|
|
|
/* @generated */
|
|
|
|
|
digraph cfg {
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_1" [label="1: Start operator!=\nFormals: i1:iterator&(byval) i2:iterator&(byval)\nLocals: 0$?%__sil_tmpSIL_temp_conditional___n$0:_Bool \n DECLARE_LOCALS(&return,&0$?%__sil_tmpSIL_temp_conditional___n$0); [line 21, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_1" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_4" ;
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_2" [label="2: Exit operator!= \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_3" [label="3: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_3" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_9" ;
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_4" [label="4: BinaryOperatorStmt: NE \n n$1=*&i1:iterator& [line 21, column 52]\n n$2=*n$1.val:int [line 21, column 52]\n n$3=*&i2:iterator& [line 21, column 62]\n n$4=*n$3.val:int [line 21, column 62]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_4" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_5" ;
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_4" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_6" ;
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_5" [label="5: Prune (true branch, boolean exp) \n PRUNE((n$2 != n$4), true); [line 21, column 52]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_5" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_7" ;
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_6" [label="6: Prune (false branch, boolean exp) \n PRUNE(!(n$2 != n$4), false); [line 21, column 52]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_6" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_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
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_7" [label="7: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$0:_Bool=1 [line 21, column 52]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_7" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_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
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_8" [label="8: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$0:_Bool=0 [line 21, column 52]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_8" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_3" ;
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_9" [label="9: Return Stmt \n n$5=*&0$?%__sil_tmpSIL_temp_conditional___n$0:_Bool [line 21, column 52]\n *&return:_Bool=n$5 [line 21, column 45]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_9" -> "operator!=#4715710375716659667.eb4126b3edd381f3092a9e38275754d4_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_1" [label="1: Start test\nFormals: \nLocals: __end:iterator 0$?%__sil_tmpSIL_materialize_temp__n$3:iterator __begin:iterator 0$?%__sil_tmpSIL_materialize_temp__n$9:iterator 0$?%__sil_tmp__temp_return_n$17:iterator 0$?%__sil_tmp__temp_construct_n$19:iterator 0$?%__sil_tmp__temp_construct_n$21:iterator temp:int value:int __range:vec& vector:vec \n DECLARE_LOCALS(&return,&__end,&0$?%__sil_tmpSIL_materialize_temp__n$3,&__begin,&0$?%__sil_tmpSIL_materialize_temp__n$9,&0$?%__sil_tmp__temp_return_n$17,&0$?%__sil_tmp__temp_construct_n$19,&0$?%__sil_tmp__temp_construct_n$21,&temp,&value,&__range,&vector); [line 35, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_1" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_13" ;
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_2" [label="2: Exit test \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_3" [label="3: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_3" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_4" [label="4: DeclStmt \n n$4=*&__range:vec& [line 37, column 18]\n _=*n$4:vec [line 37, column 18]\n n$7=_fun_vec_end(n$4:vec&,&0$?%__sil_tmpSIL_materialize_temp__n$3:iterator*) [line 37, column 18]\n n$8=_fun_iterator_iterator(&__end:iterator*,&0$?%__sil_tmpSIL_materialize_temp__n$3:iterator&) [line 37, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_4" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_5" [label="5: DeclStmt \n n$10=*&__range:vec& [line 37, column 18]\n _=*n$10:vec [line 37, column 18]\n n$13=_fun_vec_begin(n$10:vec&,&0$?%__sil_tmpSIL_materialize_temp__n$9:iterator*) [line 37, column 18]\n n$14=_fun_iterator_iterator(&__begin:iterator*,&0$?%__sil_tmpSIL_materialize_temp__n$9:iterator&) [line 37, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_5" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_6" [label="6: Call _fun_iterator_operator++ \n n$18=_fun_iterator_operator++(&__begin:iterator&,&0$?%__sil_tmp__temp_return_n$17:iterator*) [line 37, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_6" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_7" [label="7: Call _fun_operator!= \n n$20=_fun_iterator_iterator(&0$?%__sil_tmp__temp_construct_n$19:iterator*,&__begin:iterator&) [line 37, column 18]\n n$22=_fun_iterator_iterator(&0$?%__sil_tmp__temp_construct_n$21:iterator*,&__end:iterator&) [line 37, column 18]\n n$23=_fun_operator!=(&0$?%__sil_tmp__temp_construct_n$19:iterator,&0$?%__sil_tmp__temp_construct_n$21:iterator) [line 37, column 18]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_7" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_8" ;
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_7" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_8" [label="8: Prune (true branch, for loop) \n PRUNE(n$23, true); [line 37, column 18]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_8" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_9" [label="9: Prune (false branch, for loop) \n PRUNE(!n$23, false); [line 37, column 18]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_9" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_10" [label="10: DeclStmt \n n$26=*&value:int [line 38, column 16]\n n$27=*&value:int [line 38, column 24]\n *&temp:int=((n$26 * n$27) + 10) [line 38, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_10" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_11" [label="11: DeclStmt \n n$29=_fun_iterator_operator*(&__begin:iterator&) [line 37, column 18]\n *&value:int=n$29 [line 37, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_11" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_10" ;
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_12" [label="12: DeclStmt \n *&__range:vec&=&vector [line 37, column 20]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_12" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_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
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_13" [label="13: DeclStmt \n n$31=_fun_vec_vec(&vector:vec*,10:int) [line 36, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_13" -> "test#18241244337164948030.afc14f193ad97442f67ac7183be789bc_12" ;
|
|
|
|
|
"begin#vec#(1866137161906470488).7bca21f38283b3487a15399a2f8cb73c_1" [label="1: Start vec_begin\nFormals: this:vec* __return_param:iterator*\nLocals: \n DECLARE_LOCALS(&return); [line 28, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"begin#vec#(1866137161906470488).7bca21f38283b3487a15399a2f8cb73c_1" -> "begin#vec#(1866137161906470488).7bca21f38283b3487a15399a2f8cb73c_3" ;
|
|
|
|
|
"begin#vec#(1866137161906470488).7bca21f38283b3487a15399a2f8cb73c_2" [label="2: Exit vec_begin \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"begin#vec#(1866137161906470488).7bca21f38283b3487a15399a2f8cb73c_3" [label="3: Return Stmt \n n$0=*&__return_param:iterator* [line 28, column 22]\n n$1=*&this:vec* [line 28, column 29]\n n$2=_fun_iterator_iterator(n$0:iterator*,n$1.begin_:iterator&) [line 28, column 29]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"begin#vec#(1866137161906470488).7bca21f38283b3487a15399a2f8cb73c_3" -> "begin#vec#(1866137161906470488).7bca21f38283b3487a15399a2f8cb73c_2" ;
|
|
|
|
|
"end#vec#(14240882620331653738).9e08a46e9d5bcb3339794674882c80a3_1" [label="1: Start vec_end\nFormals: this:vec* __return_param:iterator*\nLocals: \n DECLARE_LOCALS(&return); [line 29, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"end#vec#(14240882620331653738).9e08a46e9d5bcb3339794674882c80a3_1" -> "end#vec#(14240882620331653738).9e08a46e9d5bcb3339794674882c80a3_3" ;
|
|
|
|
|
"end#vec#(14240882620331653738).9e08a46e9d5bcb3339794674882c80a3_2" [label="2: Exit vec_end \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"end#vec#(14240882620331653738).9e08a46e9d5bcb3339794674882c80a3_3" [label="3: Return Stmt \n n$0=*&__return_param:iterator* [line 29, column 20]\n n$1=*&this:vec* [line 29, column 27]\n n$2=_fun_iterator_iterator(n$0:iterator*,n$1.end_:iterator&) [line 29, column 27]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"end#vec#(14240882620331653738).9e08a46e9d5bcb3339794674882c80a3_3" -> "end#vec#(14240882620331653738).9e08a46e9d5bcb3339794674882c80a3_2" ;
|
|
|
|
|
"iterator#iterator#{11413353760466671846|constexpr}.a278508d3bccc69caf1a1db6246cf788_1" [label="1: Start iterator_iterator\nFormals: this:iterator* __param_0:iterator const &\nLocals: \n DECLARE_LOCALS(&return); [line 11, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"iterator#iterator#{11413353760466671846|constexpr}.a278508d3bccc69caf1a1db6246cf788_1" -> "iterator#iterator#{11413353760466671846|constexpr}.a278508d3bccc69caf1a1db6246cf788_3" ;
|
|
|
|
|
"iterator#iterator#{11413353760466671846|constexpr}.a278508d3bccc69caf1a1db6246cf788_2" [label="2: Exit iterator_iterator \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
|
|
|
"iterator#iterator#{11413353760466671846|constexpr}.a278508d3bccc69caf1a1db6246cf788_3" [label="3: Constructor Init \n n$2=*&this:iterator* [line 11, column 8]\n n$3=*&__param_0:iterator const & [line 11, column 8]\n n$4=*n$3.val:int [line 11, column 8]\n *n$2.val:int=n$4 [line 11, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"iterator#iterator#{11413353760466671846|constexpr}.a278508d3bccc69caf1a1db6246cf788_3" -> "iterator#iterator#{11413353760466671846|constexpr}.a278508d3bccc69caf1a1db6246cf788_2" ;
|
|
|
|
|
"iterator#iterator#{17107199916075329459}.2fc51ac860d26e778b9b34e5032f02d5_1" [label="1: Start iterator_iterator\nFormals: this:iterator*\nLocals: \n DECLARE_LOCALS(&return); [line 11, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"iterator#iterator#{17107199916075329459}.2fc51ac860d26e778b9b34e5032f02d5_1" -> "iterator#iterator#{17107199916075329459}.2fc51ac860d26e778b9b34e5032f02d5_2" ;
|
|
|
|
|
"iterator#iterator#{17107199916075329459}.2fc51ac860d26e778b9b34e5032f02d5_2" [label="2: Exit iterator_iterator \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"iterator#iterator#{3083368405611515834|constexpr}.86fcbefb2af88c097bfa7e085c4b4f40_1" [label="1: Start iterator_iterator\nFormals: this:iterator* __param_0:iterator&\nLocals: \n DECLARE_LOCALS(&return); [line 11, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"iterator#iterator#{3083368405611515834|constexpr}.86fcbefb2af88c097bfa7e085c4b4f40_1" -> "iterator#iterator#{3083368405611515834|constexpr}.86fcbefb2af88c097bfa7e085c4b4f40_3" ;
|
|
|
|
|
"iterator#iterator#{3083368405611515834|constexpr}.86fcbefb2af88c097bfa7e085c4b4f40_2" [label="2: Exit iterator_iterator \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
|
|
|
"iterator#iterator#{3083368405611515834|constexpr}.86fcbefb2af88c097bfa7e085c4b4f40_3" [label="3: Constructor Init \n n$2=*&this:iterator* [line 11, column 8]\n n$3=*&__param_0:iterator& [line 11, column 8]\n n$4=*n$3.val:int [line 11, column 8]\n *n$2.val:int=n$4 [line 11, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"iterator#iterator#{3083368405611515834|constexpr}.86fcbefb2af88c097bfa7e085c4b4f40_3" -> "iterator#iterator#{3083368405611515834|constexpr}.86fcbefb2af88c097bfa7e085c4b4f40_2" ;
|
|
|
|
|
"operator*#iterator#(14296957122470685412).e3f593369544fc43a253ad1e4f5ed136_1" [label="1: Start iterator_operator*\nFormals: this:iterator*\nLocals: \n DECLARE_LOCALS(&return); [line 17, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator*#iterator#(14296957122470685412).e3f593369544fc43a253ad1e4f5ed136_1" -> "operator*#iterator#(14296957122470685412).e3f593369544fc43a253ad1e4f5ed136_3" ;
|
|
|
|
|
"operator*#iterator#(14296957122470685412).e3f593369544fc43a253ad1e4f5ed136_2" [label="2: Exit iterator_operator* \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator*#iterator#(14296957122470685412).e3f593369544fc43a253ad1e4f5ed136_3" [label="3: Return Stmt \n n$0=*&this:iterator* [line 18, column 12]\n n$1=*n$0.val:int [line 18, column 12]\n *&return:int=n$1 [line 18, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator*#iterator#(14296957122470685412).e3f593369544fc43a253ad1e4f5ed136_3" -> "operator*#iterator#(14296957122470685412).e3f593369544fc43a253ad1e4f5ed136_2" ;
|
|
|
|
|
"operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_1" [label="1: Start iterator_operator++\nFormals: this:iterator* __return_param:iterator*\nLocals: \n DECLARE_LOCALS(&return); [line 13, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_1" -> "operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_4" ;
|
|
|
|
|
"operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_2" [label="2: Exit iterator_operator++ \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_3" [label="3: Return Stmt \n n$0=*&__return_param:iterator* [line 15, column 5]\n n$1=*&this:iterator* [line 15, column 13]\n n$2=_fun_iterator_iterator(n$0:iterator*,n$1:iterator&) [line 15, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_3" -> "operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_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
|
|
|
"operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_4" [label="4: BinaryOperatorStmt: AddAssign \n n$4=*&this:iterator* [line 14, column 5]\n n$5=*n$4.val:int [line 14, column 5]\n *n$4.val:int=(n$5 + 1) [line 14, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_4" -> "operator++#iterator#(14034081864165661659).8f8d47641e87add0a7463df1d1fa7b15_3" ;
|
|
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_1" [label="1: Start vec_vec\nFormals: this:vec* size:int\nLocals: \n DECLARE_LOCALS(&return); [line 24, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_1" -> "vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_6" ;
|
|
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_2" [label="2: Exit vec_vec \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
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_3" [label="3: BinaryOperatorStmt: Assign \n n$1=*&this:vec* [line 26, column 5]\n n$2=*&size:int [line 26, column 16]\n *n$1.end_.val:int=n$2 [line 26, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_3" -> "vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_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
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_4" [label="4: BinaryOperatorStmt: Assign \n n$3=*&this:vec* [line 25, column 5]\n *n$3.begin_.val:int=0 [line 25, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_4" -> "vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_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
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_5" [label="5: Constructor Init \n n$4=*&this:vec* [line 24, column 3]\n n$5=_fun_iterator_iterator(n$4.end_:iterator*) [line 24, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_5" -> "vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_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
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_6" [label="6: Constructor Init \n n$6=*&this:vec* [line 24, column 3]\n n$7=_fun_iterator_iterator(n$6.begin_:iterator*) [line 24, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_6" -> "vec#vec#{13876720186060950809}.c3c9a518fcec87e97d6b52a59f13d428_5" ;
|
|
|
|
|
}
|
