|
|
|
|
/* @generated */
|
|
|
|
|
digraph cfg {
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_1" [label="1: Start objc_blockMyBlock_array_1\nFormals: object:objc_object* idx:unsigned long stop:_Bool*\nLocals: ShouldStop:int \n DECLARE_LOCALS(&return,&ShouldStop); [line 21, column 33]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_1" -> "objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_5" ;
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_1" -> "objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_6" ;
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_2" [label="2: Exit objc_blockMyBlock_array_1 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_3" [label="3: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_3" -> "objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_4" ;
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_4" [label="4: between_join_and_exit \n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_4" -> "objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_2" ;
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_5" [label="5: Prune (true branch, if) \n n$1=*&ShouldStop:int [line 26, column 9]\n PRUNE(n$1, true); [line 26, column 9]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_5" -> "objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_7" ;
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_6" [label="6: Prune (false branch, if) \n n$1=*&ShouldStop:int [line 26, column 9]\n PRUNE(!n$1, false); [line 26, column 9]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_6" -> "objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_3" ;
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_7" [label="7: BinaryOperatorStmt: Assign \n n$2=*&stop:_Bool* [line 27, column 8]\n *n$2:_Bool=1 [line 27, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_7" -> "objc_blockMyBlock_array_1.876ea7470c254ef92f8b4921d5f810e1_3" ;
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_1" [label="1: Start objc_blockMyBlock_array_trans_2\nFormals: object:objc_object* idx:unsigned long stop:_Bool*\nLocals: ShouldStop:int \n DECLARE_LOCALS(&return,&ShouldStop); [line 40, column 7]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_1" -> "objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_5" ;
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_1" -> "objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_6" ;
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_2" [label="2: Exit objc_blockMyBlock_array_trans_2 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_3" [label="3: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_3" -> "objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_4" ;
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_4" [label="4: between_join_and_exit \n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_4" -> "objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_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
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_5" [label="5: Prune (true branch, if) \n n$32=*&ShouldStop:int [line 44, column 13]\n PRUNE(n$32, true); [line 44, column 13]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_5" -> "objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_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
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_6" [label="6: Prune (false branch, if) \n n$32=*&ShouldStop:int [line 44, column 13]\n PRUNE(!n$32, false); [line 44, column 13]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_6" -> "objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_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
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_7" [label="7: BinaryOperatorStmt: Assign \n n$33=*&stop:_Bool* [line 45, column 12]\n *n$33:_Bool=1 [line 45, column 11]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_7" -> "objc_blockMyBlock_array_trans_2.5153520a659dce1fe6582bd44cf47e84_3" ;
|
|
|
|
|
"array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_1" [label="1: Start MyBlock_array\nFormals: self:MyBlock*\nLocals: a:NSArray* \n DECLARE_LOCALS(&return,&a); [line 18, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_1" -> "array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_4" ;
|
|
|
|
|
"array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_2" [label="2: Exit MyBlock_array \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
|
|
|
"array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_3" [label="3: Message Call: enumerateObjectsUsingBlock: \n n$5=*&a:NSArray* [line 21, column 4]\n n$6=_fun_NSArray_enumerateObjectsUsingBlock:(n$5:NSArray*,(_fun_objc_blockMyBlock_array_1):_fn_(*)) virtual block_params [line 21, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_3" -> "array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_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
|
|
|
"array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_4" [label="4: DeclStmt \n n$7=_fun___objc_alloc_no_fail(sizeof(t=NSArray):unsigned long) [line 20, column 17]\n n$8=_fun_NSArray_init(n$7:NSArray*) virtual [line 20, column 16]\n *&a:NSArray*=n$8 [line 20, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_4" -> "array#MyBlock#instance.8be6e5b5e968d186440e1931c9eb40de_3" ;
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_1" [label="1: Start MyBlock_array_trans\nFormals: self:MyBlock*\nLocals: idx:unsigned long object:objc_object* stop:_Bool* enumerateObjectsUsingBlock:_fn_(*) objects:NSArray* a:NSArray* \n DECLARE_LOCALS(&return,&idx,&object,&stop,&enumerateObjectsUsingBlock,&objects,&a); [line 32, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_1" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_20" ;
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_2" [label="2: Exit MyBlock_array_trans \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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_3" [label="3: Call _fun_free \n n$9=*&stop:_Bool* [line 58, column 8]\n n$10=_fun_free(n$9:void*) [line 58, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_3" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_2" ;
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_4" [label="4: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_4" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_7" ;
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_5" [label="5: DeclStmt \n *&idx:unsigned long=0 [line 51, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_5" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_6" [label="6: UnaryOperator \n n$11=*&idx:unsigned long [line 51, column 49]\n *&idx:unsigned long=(n$11 + 1) [line 51, column 49]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_6" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_7" [label="7: BinaryOperatorStmt: LT \n n$12=*&idx:unsigned long [line 51, column 28]\n n$13=*&objects:NSArray* [line 51, column 34]\n n$14=_fun_NSArray_count(n$13:NSArray*) [line 51, column 42]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_7" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_8" ;
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_7" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_8" [label="8: Prune (true branch, for loop) \n PRUNE((n$12 < n$14), true); [line 51, column 28]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_8" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_9" [label="9: Prune (false branch, for loop) \n PRUNE(!(n$12 < n$14), false); [line 51, column 28]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_9" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_3" ;
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_10" [label="10: + \n " ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_10" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_11" [label="11: BinaryOperatorStmt: EQ \n n$15=*&stop:_Bool* [line 55, column 10]\n n$16=*n$15:_Bool [line 55, column 9]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_11" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_12" ;
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_11" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_12" [label="12: Prune (true branch, if) \n PRUNE((n$16 == 1), true); [line 55, column 9]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_12" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_13" [label="13: Prune (false branch, if) \n PRUNE(!(n$16 == 1), false); [line 55, column 9]\n " shape="invhouse"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_13" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_14" [label="14: Call n$20 \n n$20=*&enumerateObjectsUsingBlock:_fn_(*) [line 54, column 5]\n n$21=*&object:objc_object* [line 54, column 32]\n n$22=*&idx:unsigned long [line 54, column 40]\n n$23=*&stop:_Bool* [line 54, column 45]\n n$24=n$20(n$21:objc_object*,n$22:unsigned long,n$23:_Bool*) [line 54, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_14" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_15" [label="15: DeclStmt \n n$26=*&objects:NSArray* [line 53, column 17]\n n$25=*&idx:unsigned long [line 53, column 25]\n n$27=_fun_NSArray_objectAtIndexedSubscript:(n$26:NSArray*,n$25:unsigned long) virtual [line 53, column 17]\n *&object:objc_object*=n$27 [line 53, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_15" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_16" [label="16: BinaryOperatorStmt: Assign \n n$29=*&stop:_Bool* [line 49, column 4]\n *n$29:_Bool=0 [line 49, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_16" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_17" [label="17: DeclStmt \n n$30=_fun_malloc_no_fail(sizeof(t=_Bool;nbytes=1):_Bool) [line 48, column 16]\n *&stop:_Bool*=n$30 [line 48, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_17" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_16" ;
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_18" [label="18: DeclStmt \n *&enumerateObjectsUsingBlock:_fn_(*)=(_fun_objc_blockMyBlock_array_trans_2) [line 39, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_18" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_19" [label="19: DeclStmt \n n$36=*&a:NSArray* [line 36, column 22]\n *&objects:NSArray*=n$36 [line 36, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_19" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_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
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_20" [label="20: DeclStmt \n n$37=_fun___objc_alloc_no_fail(sizeof(t=NSArray):unsigned long) [line 34, column 17]\n n$38=_fun_NSArray_init(n$37:NSArray*) virtual [line 34, column 16]\n *&a:NSArray*=n$38 [line 34, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_20" -> "array_trans#MyBlock#instance.13289a590560d0628a3ae5174e716a32_19" ;
|
|
|
|
|
}
|
