Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[codegen] Improved handling of records and record arrays in the code…
…gen. - Every record now gets - A dedicated "default" constructor function for allocating its members. - this is used when the variable is declared. It initializes members to their default values. - Note that this is different from default modelica record constructor. The modelica constructor is used explictly. The "default" one is used always on declaration. - A dedicated copy function for copying its members. - An array typedef to base_array. - A macro for creating an array of the record. - This uses the constructor function to create each element of the array. - This uses generic array function with the record size. - A macro for copying an array - This uses the copy function to copy each element of the array. - A macro getter to access elements of the array. - this uses the proper casting on the returned type. - We now keep bindings in TYPES_VARS in when creating a record declaration in SimCode structure. The bindings are used as default values by the "default" constructor. - Bindings of a derived record declaration are handled properly now. - If a record is a derived record with modifications, then bindings of the modifications are available in the declration scope. record A = B(k=exp); A r; // 'exp' needs to be passed to the constrcutor => A_construct(A* r, exp) {...; r->k = exp; ...} This means a default constrcutor will need those bindings passed to it explictly if it is to work correctly. Now every TYPES_VAR of a record has a boolean attribute specifiying whether it is bound from outside or not. - When collecting used functions in the BACKEND we traverse bindings of record members. - Right now this is needed because some functions get inlined and are not used by the equation system even though the model has instances of the record (since we generate constructors now we need them to be visiable even if the record is never used in a function). - The proper way to fix this would be to check if a record is used in a function and only then generate a constrcutor. OR another option is to also traverse record member bindings when doing inlining of functions (which is not done right now.) This seemed to be the simplest and probably quickest way even though we sometimes may generate a function even though it is not really used (very rarely). - Fixed copying of records in the simulation context. - If a record is being copied to simulation vars we need special handling. This is because there is no structure to simvars. The variables are scattered. Therefore there is now a copy function that writes a given record to the corresponding element in the simvars arrays. The generated function <RecName>_copy_to_vars(RecType* src, .../*simvars locations*/) is used to achive this. - Improved generation of component references in function context - We can now handle qualified crefs with subscripts anywhere in the cref. - This is done uniformly in functionContextCref template. Try to use this everywehre. - CONTEXT_FUNCTION now has a cref prefix - This is prepeneded to any cref generated in function context. This gives us some scope control. E.g. it is used in record constructor functions to make all local variable accesses prepended to a specific record name that is passed as input to the function. - Unknown size array handling. - Arrays of unknown size are arrays where at least one dimension is unknown. - If an unknown size array is declared with a default value, i.e. a binding, then it has fixed dimension sizes equal to the binding. - However if the unknown size array is declared with out a binding then it is considered flexible and can change sizes as needed. - The array representation in the runtime system ,i.e. base_array, now has a new memeber .flexible to signify this. - Handle array expressions of records i.e. {c1,c2,..} properly - Array expressions of records are handled a bit more cleanly now. - Do not sort record member variables in the record declaration. This is just absurd. - instDims in SimCodeFunction.VARIABLE is now list<DAE.dimension> not list<DAE.Expression>. This Helps to normalize handling od dimension expressions. - We really need to normalize the handling of dimension and subscript - Plus dimension and subscript related functions are not exchangable. Constructs are interpreted differntly as dimension compared to subscript and vice versa. - template dimension() now takes context as input. This is needed. - Some more minor fixes. - Casting of call expressions which return records is handled explictly now. - Change handling of casts. - Casts to modelica_integer are disabled for now. - Casts to records with different number of members are disabled for now. - Remove PARALLE_FUNCTION_CONTEXT - Use a boolean value in FUNCTION_CONTEXT instead. Most of what we do for these contexts is very similar. - Fix and rename sortIntN to countingSort. - The function can now handle non-unique lists.
- Loading branch information
Showing
47 changed files
with
1,541 additions
and
903 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
0218247
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mahge, there are 342 regressions because of this commit, mostly in building models, and only 5 improvements. I guess you should better check...
0218247
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@casella Ya. I noticed. This was caused because I forgot to update some things for the new Front-end. There were some changes in how we handle derived records. I fixed old Front-end but skipped it for the new one (on conversion from new front end structures to old DAE). It is difficult to keep track of things when a lot changes.
I am currently working on a fix for these and other regressions on master as well.