|
|
|
|
/* @generated */
|
|
|
|
|
digraph cfg {
|
|
|
|
|
"call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_1" [label="1: Start call_virtual_destructor\nFormals: \nLocals: trgl:Polygon* \n DECLARE_LOCALS(&return,&trgl); [line 70, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_1" -> "call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_4" ;
|
|
|
|
|
"call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_2" [label="2: Exit call_virtual_destructor \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
|
|
|
"call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_3" [label="3: Call delete \n n$1=*&trgl:Polygon* [line 72, column 10]\n n$2=_fun___delete(n$1:Polygon*) [line 72, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_3" -> "call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_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
|
|
|
"call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_4" [label="4: DeclStmt \n n$3=_fun___new(sizeof(t=Triangle):unsigned long) [line 71, column 19]\n n$4=_fun_Triangle_Triangle(n$3:Triangle*) [line 71, column 23]\n *&trgl:Triangle*=n$3 [line 71, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_4" -> "call_virtual_destructor#6847397116347440235.d267757a410b72cac399f5e3d0ee0f45_3" ;
|
|
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_1" [label="1: Start poly_area\nFormals: \nLocals: ppoly3:Polygon* poly:Polygon \n DECLARE_LOCALS(&return,&ppoly3,&poly); [line 53, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_1" -> "poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_5" ;
|
|
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_2" [label="2: Exit poly_area \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_3" [label="3: Return Stmt \n n$0=*&ppoly3:Polygon* [line 56, column 14]\n _=*n$0:Polygon [line 56, column 14]\n n$2=_fun_Polygon_area(n$0:Polygon*) virtual [line 56, column 14]\n *&return:int=(1 / n$2) [line 56, column 3]\n _=*&poly:Polygon [line 56, column 27]\n n$4=_fun_Polygon_~Polygon(&poly:Polygon*) virtual [line 56, column 27]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_3" -> "poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_2" ;
|
|
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_4" [label="4: DeclStmt \n *&ppoly3:Polygon*=&poly [line 55, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_4" -> "poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_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
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_5" [label="5: DeclStmt \n n$6=_fun_Polygon_Polygon(&poly:Polygon*) [line 54, column 11]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_5" -> "poly_area#4209622570361008343.816833144841084a7fd6071bbff4c354_4" ;
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_1" [label="1: Start rect_area\nFormals: \nLocals: ppoly1:Polygon* rect:Rectangle \n DECLARE_LOCALS(&return,&ppoly1,&rect); [line 38, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_1" -> "rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_6" ;
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_2" [label="2: Exit rect_area \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_3" [label="3: Return Stmt \n n$0=*&ppoly1:Polygon* [line 42, column 15]\n _=*n$0:Polygon [line 42, column 15]\n n$2=_fun_Polygon_area(n$0:Polygon*) virtual [line 42, column 15]\n *&return:int=(1 / (n$2 - 20)) [line 42, column 3]\n _=*&rect:Rectangle [line 42, column 34]\n n$4=_fun_Rectangle_~Rectangle(&rect:Rectangle*) virtual [line 42, column 34]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_3" -> "rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_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
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_4" [label="4: Call _fun_Polygon_set_values \n n$6=*&ppoly1:Polygon* [line 41, column 3]\n _=*n$6:Polygon [line 41, column 3]\n n$8=_fun_Polygon_set_values(n$6:Polygon*,4:int,5:int) [line 41, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_4" -> "rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_3" ;
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_5" [label="5: DeclStmt \n *&ppoly1:Rectangle*=&rect [line 40, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_5" -> "rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_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
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_6" [label="6: DeclStmt \n n$9=_fun_Rectangle_Rectangle(&rect:Rectangle*) [line 39, column 13]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_6" -> "rect_area#9087317270636867019.dedb17c23e2d96ddd6e1087003e78815_5" ;
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_1" [label="1: Start tri_area\nFormals: \nLocals: ppoly2:Polygon* poly:Polygon trgl:Triangle \n DECLARE_LOCALS(&return,&ppoly2,&poly,&trgl); [line 45, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_1" -> "tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_7" ;
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_2" [label="2: Exit tri_area \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_3" [label="3: Return Stmt \n n$0=*&ppoly2:Polygon* [line 50, column 15]\n _=*n$0:Polygon [line 50, column 15]\n n$2=_fun_Polygon_area(n$0:Polygon*) virtual [line 50, column 15]\n *&return:int=(1 / (n$2 - 10)) [line 50, column 3]\n _=*&poly:Polygon [line 50, column 34]\n n$4=_fun_Polygon_~Polygon(&poly:Polygon*) virtual [line 50, column 34]\n _=*&trgl:Triangle [line 50, column 34]\n n$6=_fun_Triangle_~Triangle(&trgl:Triangle*) virtual [line 50, column 34]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_3" -> "tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_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
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_4" [label="4: Call _fun_Polygon_set_values \n n$8=*&ppoly2:Polygon* [line 49, column 3]\n _=*n$8:Polygon [line 49, column 3]\n n$10=_fun_Polygon_set_values(n$8:Polygon*,4:int,5:int) [line 49, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_4" -> "tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_3" ;
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_5" [label="5: DeclStmt \n *&ppoly2:Triangle*=&trgl [line 48, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_5" -> "tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_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
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_6" [label="6: DeclStmt \n n$11=_fun_Polygon_Polygon(&poly:Polygon*) [line 47, column 11]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_6" -> "tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_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
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_7" [label="7: DeclStmt \n n$12=_fun_Triangle_Triangle(&trgl:Triangle*) [line 46, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_7" -> "tri_area#1215149030941579879.cc7663ab4ea89457778545059b70bc38_6" ;
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_1" [label="1: Start tri_not_virtual_area\nFormals: \nLocals: ppoly2:Polygon* poly:Polygon trgl:Triangle \n DECLARE_LOCALS(&return,&ppoly2,&poly,&trgl); [line 59, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_1" -> "tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_7" ;
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_2" [label="2: Exit tri_not_virtual_area \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_3" [label="3: Return Stmt \n n$0=*&ppoly2:Polygon* [line 64, column 14]\n _=*n$0:Polygon [line 64, column 14]\n n$2=_fun_Polygon_area(n$0:Polygon*) [line 64, column 14]\n *&return:int=(1 / n$2) [line 64, column 3]\n _=*&poly:Polygon [line 64, column 36]\n n$4=_fun_Polygon_~Polygon(&poly:Polygon*) virtual [line 64, column 36]\n _=*&trgl:Triangle [line 64, column 36]\n n$6=_fun_Triangle_~Triangle(&trgl:Triangle*) virtual [line 64, column 36]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_3" -> "tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_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
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_4" [label="4: Call _fun_Polygon_set_values \n n$8=*&ppoly2:Polygon* [line 63, column 3]\n _=*n$8:Polygon [line 63, column 3]\n n$10=_fun_Polygon_set_values(n$8:Polygon*,4:int,5:int) [line 63, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_4" -> "tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_3" ;
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_5" [label="5: DeclStmt \n *&ppoly2:Triangle*=&trgl [line 62, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_5" -> "tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_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
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_6" [label="6: DeclStmt \n n$11=_fun_Polygon_Polygon(&poly:Polygon*) [line 61, column 11]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_6" -> "tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_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
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_7" [label="7: DeclStmt \n n$12=_fun_Triangle_Triangle(&trgl:Triangle*) [line 60, column 12]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_7" -> "tri_not_virtual_area#9435562296359660595.88e7106fc7dcfd34401502a9deb415ac_6" ;
|
|
|
|
|
"Polygon#Polygon#{10850889526924573388}.39fcc5831c0234f5743317d6969628c2_1" [label="1: Start Polygon_Polygon\nFormals: this:Polygon*\nLocals: \n DECLARE_LOCALS(&return); [line 10, column 7]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Polygon#Polygon#{10850889526924573388}.39fcc5831c0234f5743317d6969628c2_1" -> "Polygon#Polygon#{10850889526924573388}.39fcc5831c0234f5743317d6969628c2_2" ;
|
|
|
|
|
"Polygon#Polygon#{10850889526924573388}.39fcc5831c0234f5743317d6969628c2_2" [label="2: Exit Polygon_Polygon \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Rectangle#Rectangle#{548993796743293985}.386f89cceb4c14e4fc014bcc1ec86f4b_1" [label="1: Start Rectangle_Rectangle\nFormals: this:Rectangle*\nLocals: \n DECLARE_LOCALS(&return); [line 23, column 7]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Rectangle#Rectangle#{548993796743293985}.386f89cceb4c14e4fc014bcc1ec86f4b_1" -> "Rectangle#Rectangle#{548993796743293985}.386f89cceb4c14e4fc014bcc1ec86f4b_3" ;
|
|
|
|
|
"Rectangle#Rectangle#{548993796743293985}.386f89cceb4c14e4fc014bcc1ec86f4b_2" [label="2: Exit Rectangle_Rectangle \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
|
|
|
"Rectangle#Rectangle#{548993796743293985}.386f89cceb4c14e4fc014bcc1ec86f4b_3" [label="3: Constructor Init \n n$2=*&this:Rectangle* [line 23, column 7]\n n$3=_fun_Polygon_Polygon(n$2:Rectangle*) [line 23, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Rectangle#Rectangle#{548993796743293985}.386f89cceb4c14e4fc014bcc1ec86f4b_3" -> "Rectangle#Rectangle#{548993796743293985}.386f89cceb4c14e4fc014bcc1ec86f4b_2" ;
|
|
|
|
|
"Triangle#Triangle#{15421032765127472541}.26bfd28d102273793a62fe013a50a7d1_1" [label="1: Start Triangle_Triangle\nFormals: this:Triangle*\nLocals: \n DECLARE_LOCALS(&return); [line 29, column 7]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Triangle#Triangle#{15421032765127472541}.26bfd28d102273793a62fe013a50a7d1_1" -> "Triangle#Triangle#{15421032765127472541}.26bfd28d102273793a62fe013a50a7d1_3" ;
|
|
|
|
|
"Triangle#Triangle#{15421032765127472541}.26bfd28d102273793a62fe013a50a7d1_2" [label="2: Exit Triangle_Triangle \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
|
|
|
"Triangle#Triangle#{15421032765127472541}.26bfd28d102273793a62fe013a50a7d1_3" [label="3: Constructor Init \n n$2=*&this:Triangle* [line 29, column 7]\n n$3=_fun_Polygon_Polygon(n$2:Triangle*) [line 29, column 7]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Triangle#Triangle#{15421032765127472541}.26bfd28d102273793a62fe013a50a7d1_3" -> "Triangle#Triangle#{15421032765127472541}.26bfd28d102273793a62fe013a50a7d1_2" ;
|
|
|
|
|
"__infer_inner_destructor_~Triangle#Triangle#(14073216405110724792).c04c3fa3cd50a3125c149616f3af0105_1" [label="1: Start Triangle___infer_inner_destructor_~Triangle\nFormals: this:Triangle*\nLocals: \n DECLARE_LOCALS(&return); [line 31, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"__infer_inner_destructor_~Triangle#Triangle#(14073216405110724792).c04c3fa3cd50a3125c149616f3af0105_1" -> "__infer_inner_destructor_~Triangle#Triangle#(14073216405110724792).c04c3fa3cd50a3125c149616f3af0105_3" ;
|
|
|
|
|
"__infer_inner_destructor_~Triangle#Triangle#(14073216405110724792).c04c3fa3cd50a3125c149616f3af0105_2" [label="2: Exit Triangle___infer_inner_destructor_~Triangle \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"__infer_inner_destructor_~Triangle#Triangle#(14073216405110724792).c04c3fa3cd50a3125c149616f3af0105_3" [label="3: Destruction \n n$0=*&this:Triangle* [line 31, column 15]\n _=*n$0:Triangle [line 31, column 15]\n n$2=_fun_Polygon___infer_inner_destructor_~Polygon(n$0:Triangle*) virtual [line 31, column 15]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"__infer_inner_destructor_~Triangle#Triangle#(14073216405110724792).c04c3fa3cd50a3125c149616f3af0105_3" -> "__infer_inner_destructor_~Triangle#Triangle#(14073216405110724792).c04c3fa3cd50a3125c149616f3af0105_2" ;
|
|
|
|
|
"area#Polygon#(14534668876010564879).ccccc470b1eafda401273f4b27bbfa9f_1" [label="1: Start Polygon_area\nFormals: this:Polygon*\nLocals: \n DECLARE_LOCALS(&return); [line 20, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Polygon#(14534668876010564879).ccccc470b1eafda401273f4b27bbfa9f_1" -> "area#Polygon#(14534668876010564879).ccccc470b1eafda401273f4b27bbfa9f_3" ;
|
|
|
|
|
"area#Polygon#(14534668876010564879).ccccc470b1eafda401273f4b27bbfa9f_2" [label="2: Exit Polygon_area \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Polygon#(14534668876010564879).ccccc470b1eafda401273f4b27bbfa9f_3" [label="3: Return Stmt \n *&return:int=0 [line 20, column 24]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Polygon#(14534668876010564879).ccccc470b1eafda401273f4b27bbfa9f_3" -> "area#Polygon#(14534668876010564879).ccccc470b1eafda401273f4b27bbfa9f_2" ;
|
|
|
|
|
"area#Rectangle#(14534668876010564879).9b17971eaa6024f5a21d98d4b495fbd8_1" [label="1: Start Rectangle_area\nFormals: this:Rectangle*\nLocals: \n DECLARE_LOCALS(&return); [line 26, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Rectangle#(14534668876010564879).9b17971eaa6024f5a21d98d4b495fbd8_1" -> "area#Rectangle#(14534668876010564879).9b17971eaa6024f5a21d98d4b495fbd8_3" ;
|
|
|
|
|
"area#Rectangle#(14534668876010564879).9b17971eaa6024f5a21d98d4b495fbd8_2" [label="2: Exit Rectangle_area \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Rectangle#(14534668876010564879).9b17971eaa6024f5a21d98d4b495fbd8_3" [label="3: Return Stmt \n n$0=*&this:Rectangle* [line 26, column 23]\n n$1=*n$0.width:int [line 26, column 23]\n n$2=*&this:Rectangle* [line 26, column 31]\n n$3=*n$2.height:int [line 26, column 31]\n *&return:int=(n$1 * n$3) [line 26, column 16]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Rectangle#(14534668876010564879).9b17971eaa6024f5a21d98d4b495fbd8_3" -> "area#Rectangle#(14534668876010564879).9b17971eaa6024f5a21d98d4b495fbd8_2" ;
|
|
|
|
|
"area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_1" [label="1: Start Triangle_area\nFormals: this:Triangle*\nLocals: x:int \n DECLARE_LOCALS(&return,&x); [line 32, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_1" -> "area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_4" ;
|
|
|
|
|
"area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_2" [label="2: Exit Triangle_area \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_3" [label="3: Return Stmt \n n$0=*&x:int [line 34, column 12]\n *&return:int=(n$0 - 10) [line 34, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_3" -> "area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_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
|
|
|
"area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_4" [label="4: DeclStmt \n n$2=*&this:Triangle* [line 33, column 13]\n n$3=*n$2.width:int [line 33, column 13]\n n$4=*&this:Triangle* [line 33, column 21]\n n$5=*n$4.height:int [line 33, column 21]\n *&x:int=(n$3 * n$5) [line 33, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_4" -> "area#Triangle#(14534668876010564879).b2c96bbb8f170e9d12180637dc0d6da3_3" ;
|
|
|
|
|
"set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_1" [label="1: Start Polygon_set_values\nFormals: this:Polygon* a:int b:int\nLocals: \n DECLARE_LOCALS(&return); [line 16, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_1" -> "set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_4" ;
|
|
|
|
|
"set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_2" [label="2: Exit Polygon_set_values \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
|
|
|
"set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_3" [label="3: BinaryOperatorStmt: Assign \n n$1=*&this:Polygon* [line 18, column 5]\n n$2=*&b:int [line 18, column 14]\n *n$1.height:int=n$2 [line 18, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_3" -> "set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_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
|
|
|
"set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_4" [label="4: BinaryOperatorStmt: Assign \n n$3=*&this:Polygon* [line 17, column 5]\n n$4=*&a:int [line 17, column 13]\n *n$3.width:int=n$4 [line 17, column 5]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_4" -> "set_values#Polygon#(2698446688876490094).f9216ba6d3085c8bce59aeddec27f348_3" ;
|
|
|
|
|
"~Triangle#Triangle#(14073216405110724792).8adff4889e6d988a35e49531a9afaad5_1" [label="1: Start Triangle_~Triangle\nFormals: this:Triangle*\nLocals: \n DECLARE_LOCALS(&return); [line 31, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"~Triangle#Triangle#(14073216405110724792).8adff4889e6d988a35e49531a9afaad5_1" -> "~Triangle#Triangle#(14073216405110724792).8adff4889e6d988a35e49531a9afaad5_3" ;
|
|
|
|
|
"~Triangle#Triangle#(14073216405110724792).8adff4889e6d988a35e49531a9afaad5_2" [label="2: Exit Triangle_~Triangle \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"~Triangle#Triangle#(14073216405110724792).8adff4889e6d988a35e49531a9afaad5_3" [label="3: Destruction \n n$0=*&this:Triangle* [line 31, column 15]\n _=*n$0:Triangle [line 31, column 15]\n n$2=_fun_Triangle___infer_inner_destructor_~Triangle(n$0:Triangle*) virtual [line 31, column 15]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"~Triangle#Triangle#(14073216405110724792).8adff4889e6d988a35e49531a9afaad5_3" -> "~Triangle#Triangle#(14073216405110724792).8adff4889e6d988a35e49531a9afaad5_2" ;
|
|
|
|
|
}
|
