forked from rose-compiler/rose
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
1172 lines (886 loc) · 52.2 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
* TODO file for ROSE -*- outline -*-
Tell us if you feel like volunteering for any of these ideas, listed
more or less in decreasing order of priority. Some TODO items are
implicit from received email. Significant contributions require
written assignments and disclaimers.
-----------------
June 27, 2008 Clean up the ROSE source tree for the public release
SciDAC repository:
ROSE (core)
EDG Binaries
Open Fortran Parser jar file
Local repository:
EDG source
Testsuite:
POP,
OMP tests,
developerscratch,
Python example test,
ROSEHPCT tests
Old projects:
SimpleCallGraph
CompassDist
BinaryContextlookup
DatalogAnalysis
MOPS
A++1999/2003
OMPPreprocessor
Sub directories :
keep (Y) ,
GNU_HEADERS Y
qmsh Y
Papers/talks Y
TAU headers Y
A++ Y
P++ Y
OvertureCode Y
SLA Y
MSTL Y
remove (N)
OpenAnalysis N
Open64 N
TXT2HTML N
aterm_bundle N
proposals N
Boost test N
mpich N
MySQL N
COCO N
undecided
checkpoint Lib ?
PDFlib ?
-----------------
DONE * Multidimensional support is not finished yet (mostly there)
Could be made less dependent upon array objects (?)
DONE * Better unparser (in development by Gary Lee)
WORKING * Better support to automatic code generation (for grammar implementations)
* Need to implement the new transformation specification mechanism.
* Need more sophisticated examples.
DONE * Need to build Sage II in such a way that we can better maintain it
and make it portable.
DONE (see below) * Need a way to display the AST (currently we can print out the AST associated with the sage representation)
but we have no mechanism to print out what is in the EDG representation. This would be helpful.
* Need to consider the requirements of the SGI FORTRAN 95 open source front-end.
I have read the WHIRL Intermediate Language Specification and this appears to be possible.
* Require an inliner mechanism for the transformation support. Great student project!
* Reference counting of the SAGE classes has not been implemented
The referenceCount data member is there now, but it needs to be incremented and
decremented to record references. The new and delete operators have not been
implemented either (though this is not required for reference counting). This
is not a serious problem, except that it takes purify a long time to process the
memory leaks it reports (as a resutl I have turned off this test in purify
(using -leaks-at-exit=no -inuse-at-exit=no)).
* It would be good to have some simple and moderately sophisticated tree traversal
mechanisms within ROSE. Sage originally provided one, but it was difficult to use
for anything meaningful. I don't know if we could design a better one, or perhaps
the Sage version would be fine for limited sorts of operations.
Using a flag that is reset but records if graphs vertices have been processed would be
one approach. Likely a common technique.
Reasons for traversing the program tree:
1) display the program tree (this is problematic since this can amount to
endless recursion (because the program tree (AST) is not really a tree
but an arbitrary graph).
3) Analysis:
a) simple analysis
* where const is cast away
b) moderately sophisticated analysis
* recording memory access patterns (?)
* similar error checking
This might require call graph analysis and dependence analysis
c) complex analysis
* seeing the context of how statements are used together
* recognizing array statements
3) Transformations:
a) simple transformation might be possible using this approach
* instrumentation
* Converting the expanded CPP ASSERT macro back into a
call to "ASSERT(expression)";
* converting the expanded CPP NULL macro back into "NULL"
(I think this is a bit harder than ASSERT).
b) moderately sophisticated transformations
* ?
c) complex transformations, likely a traversal mechanism is not powerful
enough to recognize where these transformation should be done. But
likely once identified (using higher-level grammars) the transformations
could be automated by a tree traversal mechanism on the higher-level
grammars AST.
* array statement optimization
* DONE: As an alternative to writting out the AST as an asci file, it might be helpful to
write it out as a hypertext format so that scopes/files could be colapsed.
There must be software around that does this. Currently we output a very large
file that uses indentation to should scope, something better would be helpful
and could be folded into the SvPablo (a AST viewer?).
The current mechanism uses PDF Bookmarks to display the hierarchy. Mechanisms
are implemented to display both the EDG and SAGE ASTs. The implementation is still
incomplete and should be filled in by anyone who wants to learn about the ASTs.
The EDG AST is traversed by scope instead of by source_sequence_list entry. We
really need both since the future connection of EDG to SAGE should likely be done
using a source_sequence_list entry traversal of the EDG AST!
* The currently implemented mechanism for handling the use of extern "C" surrounding
a #include<filename> directive is limited to one #include directive per
extern "C" {} modifier. The mechanism is a bit of a hack and not very robust.
A more details comment is in the ChangeLog about what was done ans its limitations.
A better method would build the include tree and search all brances and leaves of
the include tree to verify that each declaration was really an 'extern "C" with braces'
modifier. This would suppliment the current approach which uses a lex rule to find the
'extern "C" {' modifier (when directives are extracted) and justs adds the closing
brace "}" after the next #include directive (not very safe or smart). This problem
needs to be revisited.
* DONE: Multi-file support. We will at some point need to input a collection of files
for processing. This will (at least on small enough projects) permit a full
call graph to be processed. Other mechanisms for building a project wide call
graph will have to be developed at some point (if required).
* Currently the column position can be fooled by tabs (which are counted as a
three columns). To fix this we should first make a pass (it can be optional)
over the source code to expand out all tabs (to some user defined value).
Then we can process the code through the EDG front-end and get more reliable
column data for statements and expressions. This will permit us to do a more
accurate job in the unparsing. This is not a high priority at the moment.
I have verified that TABS in ROSE are currently interpreted to be 3 spaces
(even though emacs interprets them to be 7 in my setup), and that the column
information displayed in the AST is wrong as a result.
This should be fixed before any effort at fixing other formatting problems
since this might be the cause of some of them and this issue would get in the way
of fixing other formatting problems.
* DONE: Formatting of the unparsed code is done fairly well. I think that there is some additional
line feeds inserted in the unparsing of preprocessor declarations and comments.
I don't know what tests of this should be done (or how picky we want to be).
* DONE: Call graph support is required for many other features to be added to ROSE
(e.g. dependence analysis). This is a great student project. DOT could be used to
visualize the graph (seems to work well for even large graphs in Doxygen).
* Our ROSE unparser writes directly to an output stream. I have noticed that other
unparsers used a separate structure with several function pointers (e.g. EDG).
Is this better than what we do currently? It might be that we could improve our
unparser by putting the output string into the unparser class (then again I think
this is exactly what we do). So maybe there is nothing to improve here?
* DONE: EDG records the location of "{" and "}" associated with statement blocks.
This could permit a more accurate positioning of comments in the unparsing phase.
This is not a high priority.
* It appears that the strings used to define template declarations might already be in the
EDG AST so we would not require Danny Thorne's modification of EDG to save them explicitly.
Need to finish the PDF display of the EDG AST to figure this out.
* DONE: The implementation of SAGE mixes the use of definitions with declarations in ways
that makes the code confusing. For example a SgTypedefDeclaration has a tag TYPEDEF_STMT.
This should be fixed at some point to make the naming self consistant.
* It seems that declarations of functions are output with the "(...)" arguments while member
function declarations are not (need to fix this). The temp fix for this is in the
ROSE/src/unparser/unparse_stmt.C (in the Unparser::unparseTypeDefStmt function).
* DONE: ROSE preprocessors don't correctly report when illegal options are used.
For example, "--help" yields the message:
"Assertion failed: ROSE::numberOfSourceFileNames == 1, file /home/dquinlan/ROSE/NEW_ROSE/src/command_line_options/buildCommandLine.C, line 876"
This needs to be addressed at some point.
* Unparser bug (not too major)
Functions are unparsed with function argument names missing (see TESTS/CompileTests/C++Code/test2001_11.C)
Function parameters not unparsed correctly with the variable name.
With SUN CC we are just missing the variable name:
original C++ code:
void foo (int i);
unparsed C++ code:
extern void foo (int );
* Erin Parker's try_catch_test.C fails to pass EDG and SAGE II. The fix to EDG is to
enable the exceptions_enabled in EDG/src/cmd_line.h, and the error is in SAGE II.
Within the implementation of the SgTryStmt::replace_statement(SgStatement *o, SgStatement *n)
there is a message:
printf ("ERROR: STL us not fixed in code -- exiting in SgTryStmt::replace_statement \n");
abort();
These STL iterators have to be put into place in about 5 places in the AST Restructuring Tools source.
I have modified the defaults for EDG so that EDG now accpects exception handling code. Then I modified
the C++ grammar to correctly build the AST. The remaining problem is that the unparser does not
generate the correct code. This remains as work left to do. dqDevelopmentDirectory/test2001_29.C
demonstrates the error.
* DONE Support of multiple invocations of the SgFile
EDG has a problem when EDG_MAIN is called more than once. The problem is that the command line
processing fails. To best fix so far for this problem has been to return from the top of the
EDG proc_command_line(int argc, char *argv[]) function when the value of option_descriptions_used
is greater than 0 (which seems to indicate that it is part of the second invocation instead of the
first (it is initialized to 0 as a static file scope variable). To change the primary source
filename I have modified EDG cmd_line.c to set the primary fine name to a global variable
that I have defined above the proc_command_line function in cmd_line.c. This variable is
then set by the code in specification.C. As a result the command line can not be changed
after the first invocation, except to change the primary source file. This seems to be
a good enough fix since we can assume that we only want to change the source file name between
invocations. However, it does mean that the command line (except for the source file name)
is ignored after the first invocation of the SgFile constructor (which is called by the SgProject
constructor).
* Transformations:
** Need to define interfaces for transformations.
** Need to handle multiple transformations.
** Need more examples of transformations.
** How should targets be recognized? Much of this work is done but there remain a few details:
1) Currently work uses a function which is called by the global transform function, but if we
are to bury the global transfer function within the specification mechanism then we need a
better approach. A function pointer might work well here. Templates seem to greatly complicate the
interface since then the global tree traversal mechanism would have to be templated.
2) Our primary approach within ROSE is to use the terminals of a specific grammar as targets for
transformations. The use of a function to identify the target of a transformation can hide this
and even make it optionally more specific (C++ declarations of a specific type could be a target
for example, even if just using the C++ grammar). We need examples of transformations that
use higher-level grammars (however, we need more infrastructure in place for this).
** The current function TransformationSpecificationTypes::tripAwayWrapping( SgFile & file ); does not
get the statements representing the transformation out of the function into which they are placed.
As a result the whole wrapper function is inserted into the application's AST.
* Markus Kowarschik is maintaining a separate todo file in this directory: TODO_MK
It contains a list of bugs (with detailed descriptions) to be fixed.
* Things to remove in ROSE so that the development directory checked out from CVS is easy to understand
and so that the distributions build by autoconf/automake are clear.
remove ROSE/ROSETTA/old_simpleGrammar
remove ROSE/grammar.old_dir
remove ROSE/src/SAGE
remove ROSE/src/Padding (make sure it is in the A++Preprocessor)
remove ROSE/src/PaddingTrans (make sure it is in the A++Preprocessor)
remove ROSE/src/TransformBaseClass (make sure it is in the A++Preprocessor)
remove ROSE/src/Transform_2 (make sure it is in the A++Preprocessor)
remove ROSE/src/Transform_3 (make sure it is in the A++Preprocessor)
remove ROSE/src/Transform_4 (make sure it is in the A++Preprocessor)
check ROSE/SAGE/grammarBaseClass.C (I think this is used by ROSETTA grammars or the A++ preprocessor)
check ROSE/ROSETTA/MetaProgramExample.C (make sure this is required)
check ROSE/ROSETTA/parser.C (does not seem to be used)
check ROSE/ROSETTA/*.implementation (I think these can be removed)
check ROSE/ROSETTA/*.include (I think these can be removed)
remove ROSE/ROSETTA/grammarData.C (No longer used)
Update all the README files in each directory stating the purpose and organization of the directory
* Configurations issue:
STL-1995 is a link to STL (and it should be the other way around).
STL is a directory where the 1995 version of STL is located. I'm sure that this
was some sort of mistake. But it need to be fixed so that the configuration is sane!
Currently in order to switch to a new version of STL, I have make STL-1995 a link
to the new STL located in ROSE/STLPort/STLport-4.5b8/stlport.
I have fixed the makelinks file to correctly build this "misleading" link
* Testing by different people
Each person should have a directory containing a <name>TestsDirectory and a <name>Preprocessor directory.
This would allow each person to build there own specialized preprocessor for their own testing
and there own test codes to test the preprocessor.
* Current handling of true and false are located in several locations (instead of centralized into bool.h).
* Better support for acmacros (not available to everyone doing ROSE development)
Need to have configuration check if the acmacros directory is built and if not untar the binary acmacro.tar.gz
file and use it. We will have to define a mechanism to keep this binary file up to date as well. Currently
I have built the binary acmacros.tar.gz file and added it to the cvs repository (the simple part of the process).
This is a problem for people who have access to the CVS repository but who are not in the casc group
and so cannot access Brian Gunney's cvs repository for acmacros.
* Currently ROSE will not compile with KCC on the Sun or Linux
Previously I had ROSE compiling with KCC on the SUN (so likely this is not too much to fix).
Bobby says that the problem is the same for both SUN and Linux.
****************************************************
TODO: Retargetable Compiler Support (work by Bobby):
****************************************************
There is a little bit of work remaining to make ROSE portable to different compilers. Bascially
a mechanism has been defined to permit ROSE to be made specific to any back-end C++ compiler.
However, an implementation showing how this works has only been implemented for the g++ and KCC
compilers (and the KCC example has remaining problems (on both Sun and Linux) and g++ on SUN also
currently fails). The process involves copying the compiler specific header files (suprise, all compilers
seem to have some!) to a location within the ROSE compile tree. For many compilers these files must
be edited to remove dependence upon "#include_next" (which is spelled differently by each compiler)
which has the same semantics for all compilers (at least KCC and g++). The semantics of #include_next
uses the list of include paths and permits all targets (of the #include_next <target.h>) to consider
only include directories listed AFTER the directory of the header file where the #include_next <target.h>
is read. For all compilers (that Bobby has looked at; g++ and KCC) the target of the #include_next <target.h>
is always located in "/usr/include" so "#include_next <target.h>" is equivalent to "#include </usr/include/target.h>".
We can't be sure that this is always the case. Our modification of the compiler specific header files
currently replaces all instances of "#include_next <target.h>" with "#include </usr/include/target.h>".
We will see if this is sufficently robust. Note that the semantics of #include_next does not
force the target file to have the same name as the file where the #include_next directive appears,
but this is the way it is always used and so we have taken advantage of that as well in defining
the automatic transformations of the comiler specific files.
Bobby added files: compiler-defs.m4, create_system_headers, and dirincludes to the ROSE/config directory
and modified the ROSE/ROSETTA/Grammar/Support.code file to add an optional compiler name to the
SgProject::compileOutput function and modified the construction of the -D list of options handed to
the EDG frontend to take the list from the macros defined in the config.h file.
* KCC currently fails to compile ROSE on both SUN and Linux (this used to work on the SUN so it should be to much work to fix).
Both platforms have the same problem (an STL problem). Also, Bobby reports that the configure scripts report the size
of float, int, double, etc are all ZERO. So something about the autoconf test for size of primative types needs to be
looked checked. LATER checks have confirmed that if KCC is used as the C compiler then the AC_SIZEOF_TYPE macro returns zero,
but if the default C compiler is used then the size of all tyes appear to be correct. So don't use KCC as the C compiler!
* EDG seems to have a problem being compiled with the g++ compiler on the SUN. The problem is nto that it will not
compile (it will), but that the executable built will not run. Some sort of crash when it starts to use the EDG front-end.
Not clear is this is fixable, since we don't want to work on the EDG front-end, so we will see. Debugging this
might be a job for purify or Insure.
* Currently the create_system_headers shell script can take an optional parameter to specify the source directory of the target
back-end compilers compiler-specific header files. This should eventually be able to be specified
as an option on the configure command line (perhaps the target directory should be specified on
the configure command line as well).
* In the compiler-defs.m4 shell script the compiler should have it's possible path stripped off using "compilerName=`basename $1`"
* ROSE/EDG/configure.in calls GET_COMPILER_SPECIFIC_DEFINES and so it sets the -D options and the compiler name, it might be that
only the compiler name is really needed.
* ROSE/configure.in includes a line "rm -rf '$(CXX_TEMPLATE_REPOSITORY_PATH)'" to remove the template directory that is built
when the C++ autoconf test codes are compiled before $(CXX_TEMPLATE_REPOSITORY_PATH) is defined. This avoids a directory
called "$(CXX_TEMPLATE_REPOSITORY_PATH)" in ROSE after configure has been run (which was always sort of ugly). However,
this only makes sense on the SUN using the sun C++ compiler. The fix should likely envolve a test to see what compiler
is being used so that the the "ti_files" directory can be removed when using the KCC compiler. The current test which just
removes "$(CXX_TEMPLATE_REPOSITORY_PATH)" fails if using g++ or KCC, but it seems that the configure script goes on.
* CC is now the defalt back-end C++ compiler for development on the SUN. I have added an configure option to specify
the backend directly.
*************************************************************
END of TODO section specific to Retargetable Compiler Support
*************************************************************
* Preprocessor macro definitions should perhaps not be unparsed in the final output. We might make this an option (or the default).
*************************************************************
* Configuration TODO list:
*************************************************************
DONE * Put in the AC macro call to make sure that version 2.52 or higher of autoconf is used
* Change config.h (all four of them) to edg_config.h, sage_config.h, rosetta_config.h, and rose_config.h
DONE * Call AC_CONFIG_SUBDIR multiple times dependent upon conditionals instead of just once.
DONE * Remove references to: sla_PREFIX sla_INCLUDES sla_LIBS (now that we have removed sla as an option)
DONE * Remove references to subdirectory's Makefiles within distclean-local rules (I think in ROSE/Makefile.am)
* Need a way to make it clear when "make check" has passed all tests.
*************************************************************
* END Configuration TODO list
*************************************************************
* (4/8/2002) Program Statistics Gathering
The purpose of gathering data about programs will become more clear in later research work when we
try to optimize the performance of applications. Initially we should consider just gathing
information about a target application. Such information could include:
Number of inlined functions (to determine potential overuse of inlining which could effect compile times)
Information about functions
Length of functions
Length of inlined vs. non-inlined functions
Relative location of functions (optimizations can include reordering to provide instruction cache optimizations)
Data Structures used
Complexity of data structures
Number of uses of library abstractions
Access Patterns
**************************************************************************
* (4/8/2002) Possible Summer Student Projects:
**************************************************************************
1) Unparser built on query mechanism
2) Program statistics gathering (envolves development of a lot of specialized queries)
3) Flush out more interesting parts of the Name Query and Number Query Libraries (could generate call graph).
Number of branch points (conditionals) as a metric for complexity.
4) Visualization of program analysis (generate PDF file containing AST, source code, with links to call graph,
dependence graph, etc.).
5) Cache optimization for loop carry dependence optimization of array statements (merge the two loops associated with
the case when the lhs operand appears on the rhs).
6) Include the option to introduce a transformation which times the transformed and non-transformed code.
7) Include the option to test a transformation (compute the transformed and non-transformed code and compare the results).
This could be a general transformation into which many transformation could be put (as long as they have the property
of preserving the semantics). Is semantics preservation a property in the classification of transformations?
8) Where statement transformations in A++/P++ Preprocessor
9) Indirect addressing in A++/P++ Preprocessor
10) Scalar Indexing transformation in A++/P++ Preprocessor
* We need to classify abstractions and transformations (define a hiearchy of properties that describe transformations)
Need to find some literature on this topic
Common properties associated with semantics of abstractions (upon which we introduce transformations):
Element semantics: operations on the collection are applied to the elements (with no reduction)
Reduction semantics: operations on a collection generate a smaller collection
Widdening Semantics: operations on a collection generate a larger collection
Common properties of transformations:
preserve the semantics: array transformations in A++/P++ Preprocessor (axx)
change the semantics: e.g. Automatic differentiation
11) The context should be represented in the inherited attribute, the code to represent the
context of any libraries use within an application should be generated automatically. This
should be possible for ROSETTA. This would be a project for anyone familiar with ROSETTA.
How similar is this to the recognition of abstractions or it is just the correct place to do
it.
**************************************************************************
* Documentation stuff to do
**************************************************************************
* Explain what files are generated and so should not be changed by the user
* Explain our testing process
* Explain the CVS checkin policy
**************************************************************************
* Member functions that would simplify use of Sage (future features)
**************************************************************************
* Member function in SgFunctionCallExp (and maybe SgFunctionType):
// returns true if the function is a member function (false if not a member function)
bool isMemberFunction();
// returns name of class for which function is a member (or empty string if not a member function).
string get_class_name();
**************************************************************************
* (8/11/03) Work to do before release of ROSE
**************************************************************************
SAGE work:
1) Consistant class names and function names
2) Consistant function interfaces (remove some and add others)
a. Define new function interfaces
1. getName functions at nodes containing names
2. getList (or "list") functions at nodes containing lists
3. virtual containsList function function returning bool implemented on SgNode
4. "insert" "replace" "remove" functions
1. insert would be implemented as a non-virtual function
only at the astnodes where it makes sense.
2. virtual replace function implemented on SgNode
(checks node variant and handles case replace on
list of declarations vs. list of statements)
3. remove function implemented on SgNode
5. Discuss if NULL pointeres are permited in interface.
b. Select existing functions to be removed
1. append, prepend, differnet insert functions in scopes etc.
2. getStatementList and getDeclarationList functions (in favor of "getList" or "list")
3) Fix duplicate (twin) SgInitializedName nodes
*******************************************************************************
* (9/12/2003) Program Visualization (How to Use Nil's OpenGL AST visualization)
*******************************************************************************
Visualization Software:
Visualization of Compiler Graphs (VCG):
http:https://rw4.cs.uni-sb.de/~sander/html/gsvcg1.html#description
Graph Drawing Tools and Related Work:
http:https://rw4.cs.uni-sb.de/~sander/html/gstools.html
Mkfunctmap (Call graph visualization, shows clustering by file):
http:https://seclab.cs.ucdavis.edu/~hoagland/mkfunctmap.html
Types of graphs:
1) Data Structure Graphs
* Data structure visualization in support of automated Dump/Restart code generation
* Diff of two data structures (useful for EDG updates)
* Data Stucture Dependence Graph
Given two data structures A and B, A is dependent on B iff data
used from data structure B is used to define data in data structure A.
2) Module Dependence Graphs (related to Data Stucture Dependence Graph)
* Automated Testing within massive program changes (such as occur in scientific computing)
3)
*********************
Example of how to run Nils' graphics display of dot files:
0 bash
1 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/thuerey1/local/lib/graphviz
2 cd /home/thuerey1/rose/dot3d
3 Process dot file for use with interative dot viewer
dot -Tdot test2004_11.C.dot > test2004_11.C.pdot
4 ./dot3d pl/prelayout_small.dot
5 ./dot3d pl/prelayout_xxxlarge.dot
9 ./dot3d pl/prelayout_large.dot
**************************************************************************
* (9/26/2003) Updates To SAGE Interface (Draft Proposal)
**************************************************************************
1) Rewrite mechanism level 1: insert(), replace(), remove()
taking both single SgStatement pointers and a list of SgNode pointers
2) Add member functions to SgNode to permit simple access to the SgProject, SgFile, and
SgGlobal objects higher (toward the root) in the AST.
a) SgProject* SgNode::getProject(SgNode*);
b) SgFile* SgNode::getFile(SgNode*);
c) SgGlobal* SgNode::getGlobalScope(SgNode*);
d) Maybe also, SgDeclarationStatement SgNode::getDeclaration(SgNode*);
e) SgForInitStatement* SgForStatement::getInitializerStatements();
3) Naming mechanisms (member functions which return names
a) string SgType::getName() to return the name of a type (function
currently in ROSE/src/transformationSupport)
b) string SgFunctionDeclaration::getName()
c) string SgClassDeclaration::getName()
d) string SgFunctionDeclaration::getMangledName()
e) string SgClassDeclaration::getMangledName()
4) Getting next and previous statements (at least one is implemented in ROSE::getPreviousStatement())
a) SgStatement* SgStatement::getPreviousStatement();
b) SgStatement* SgStatement::getNextStatement();
5) Generating subcollections (using the Query Library and replacing the SgSymbolTable)
a) list<SgFunctionDeclarationStatements> SgScopeStatement::functionDeclarations()
b) list<SgFunctionDeclarationStatements> SgScopeStatement::memberFunctionDeclarations()
c) list<SgVarRefExpr> SgScopeStatement::variableReferences(SgInitializedName*)
d) others, etc.
6) Symbol renaming (possible only after deleting the SgSymbolTable)
a) rename variables
b) rename types
c) rename functions
7) Things to remove:
a) enum Cxx_GrammarVariants (use enum VariantT instead)
b) SgC_PreprocessorDirectiveStatement and all derived classes
c) SgCommentStatement and all derived classes
d) SgFunctionTypeTable (not used by anyone???)
8) Things to rename
A. Change Class names
a) SgEllipse --> SgEllipsis
b) Statements named with suffix "Stmt" to be renamed with suffix "Statement"
c) Statements names that don't contain the substring "statement" should
be fix to contain the suffix "statement"
d) SgExprStatement --> SgExpressionStatement
e) SgForInitStatement --> SgForInitializerDeclarationStatement (???)
f) Affected SgStatement classes:
SgBreakStmt
SgCaseOptionStmt
SgCatchStatementSeq
SgContinueStmt
SgDeclarationStatement (see derived classes)
SgAsmStmt
SgClassDeclaration
SgTemplateInstantiationDecl
SgCtorInitializerList
SgEnumDeclaration
SgFunctionDeclaration
SgMemberFunctionDeclaration
SgFunctionParameterList
SgTemplateDeclaration
SgTypedefDeclaration
SgVariableDeclaration
SgVariableDefinition
SgDefaultOptionStmt
SgReturnStmt
SgScopeStatement (see derived classes)
SgBasicBlock
SgCatchOptionStmt
SgClassDefinition
SgTemplateInstantiationDefn
SgDoWhileStmt
SgFunctionDefinition
SgGlobal
SgIfStmt
SgWhileStmt
SgSpawnStmt
SgTryStmt
B. Change Function Names
a) Use of sage in function names
virtual const char* sage_class_name() const;
to
virtual const string className() const = 0;
b) Variant access function
variantT() const;
C. Change Enum Names
a) VariantT -> <something better>
D. Change SgBaseClassList to be a list of pointers to SgBaseClass
(this detail is an inconsistancy in SAGE III, inherited from SAGE II)
8) Previously defined TODO list* ((8/11/03) Work to do before release of ROSE)
1) Consistant class names and function names
2) Consistant function interfaces (remove some and add others)
a. Define new function interfaces
1. getName functions at nodes containing names
2. getList (or "list") functions at nodes containing lists
3. virtual containsList function function returning bool implemented on SgNode
4. "insert" "replace" "remove" functions
1. insert would be implemented as a non-virtual function
only at the astnodes where it makes sense.
2. virtual replace function implemented on SgNode
(checks node variant and handles case replace on
list of declarations vs. list of statements)
3. remove function implemented on SgNode
5. Discuss if NULL pointeres are permited in interface.
b. Select existing functions to be removed
1. append, prepend, differnet insert functions in scopes etc.
2. getStatementList and getDeclarationList functions (in favor of "getList" or "list")
3) Fix duplicate (twin) SgInitializedName nodes
9) Member function in SgFunctionCallExp (and maybe SgFunctionType):
a) // returns true if the function is a member function (false if not a member function)
bool isMemberFunction();
b) // returns name of class for which function is a member (or empty string if not a member function).
string get_class_name(); OR string getClassName();
10) Root directory reorganization
The current root directory for ROSE has a lot of subdirectories which make the project
confusing.
a) src directory does not contain but a little bit of the source code for ROSE
b) Analysis directory (what analysis is this and shouldn't several current
subdirectories of the root directory go here?
c) ExamplePreprocessors (perhaps this should be renamed to ExampleTranslators?)
d) ContainerParallelizer should not go into the root directory (I think).
If we need a location for projects and the ExamplePreprocessors directory
is not good enough, then let's build a PROJECTS (pick a better name) directory.
11) Things to Add (Possible things to add)
a) SgFunctionForwardDeclaration
Currently a forward declaration is just a normal SgFunctionDeclaration
node with a null pointer to a SgFunctionDefinition. It has a valid pointer
to a SgFunctionParameterList object but the scope of the SgFunctionParameterList
is the SgFunctionDefinition not the SgFunctionDeclaration (since a
SgFunctionDeclaration is not a SgScopeStatement object). We could add a
SgForwardFunctionDeclaration and a SgForwardFunctionParameterList which would
handle these special case. Then the SgForwardFunctionDeclaration would contain
a SgForwardFunctionParameterList, but the get_scope() function would return NULL
for a SgForwardFunctionParameterList (which is what it does now). It is not
clear if this is a problem worth fixing or not.
********************************************************************************
* (10/11/2003) Things to add to SAGE III to support F90 (Initial Draft Proposal)
********************************************************************************
This draft proposal for new IR nodes for SAGE III should open up some
discussion. I have based it largely on the documented FORTRAN 90 support
withn Sage++ (I had a copy of the old documentation at home). I have been
reviewing FORTRAN 90 (I have two books on F90) and so it has been quite
interesting. I have tried to separate out what might be new IR nodes and
what IR nodes might be reused to stand for both C++ and F90. I am still
not certain we want to have a union of IRs within SAGE III, so this detail
has to discussed still. We could use ROSETTA to build us a separate
F90 IR so that the C++ IR is unchanged. Then the input to ROSETTA would have to
specify what is shared and what belongs separately to the IRS for each language.
Then the details would appear in ROSETTA (which might be where it should be).
Many details have to be discussed and sorted out. But independent of that I
think this draft details what needs to exist in the F90 IR. Alternatively it
represents what would have to be hidden in the C++ IR (via Markus's suggested
possible approach, if we somehow encoded the F90 into the C++ (not cerain that
is possible, but we can talk about that)).
Since these would build on many existing SAGE III IR classes, I think that they
could be added without much trouble via ROSETTA. They contain no F90 semantics so
they are not complicated. The trick is only to build these so that all the
Whirl IR elements have a place to map to within SAGE III. Since there are similar
to the f90 support in Sage++, these should represent a close to complete set
of required IR nodes. And of course as Beata pointd out SAGE now starts to
come full circle on it's original implementation (but hopefuly more robust
this time with leaveraging connections to EDG for C and c++ and leveraging a
connection to Open64 for FORTRAN 90).
A. Possible new IR nodes for SAGE III (these likely match, in some way,
F90 constructs in the RICE version of Whirl (I would guess), if
source-to-source processing is possible):
SgProgramHeaderStatement : SgStatement
// Fortran Program Blocks
SgSymbol* name
SgBasicBlock* body
string getName()
SgBasicBlock* getBody()
SgProcedureHeaderStatement : SgStatement
// Fortran subroutines
SgSymbol* name
SgBasicBlock* body
string getName()
SgBasicBlock* getBody()
SgBlockDataStatement : SgStatement
// Fortran block data statements
SgSymbol* name
SgBasicBlock* body
string getName()
SgBasicBlock* getBody()
SgModuleStatement : SgStatement
// Fortran Module statements
SgSymbol* name
SgBasicBlock* body
string getName()
SgBasicBlock* getBody()
SgInterfaceStatement : SgStatement
// Fortran 90 operator interface statements
SgSymbol* name
SgBasicBlock* body
SgStatement* scope
string getName()
SgBasicBlock* getBody()
SgStatement* getScope()
SgParameterStatement : SgDeclarationStatement
// Fortran constants
SgExpression* constants
SgExpression* values
SgImplicitStatement : SgDeclarationStatement
// Fortran implicit type declarations
SgExpression* implicitLists (???)
SgStatementFunctionStatement
// Fortran statement function declarations
// likely want an initialized name list instead of name and argument lists ???
SgSymbol name
SgExpresssionList arguments
SgBasicBlock* body
SgInitilaizedNameList* arguments()
SgBasicBlock* getBody()
SgStructureDeclarationStatement
// Fortran 90 structure declarations
SgSymbol name
SgExpresssion* attributes
SgBasicBlock* body
SgExpression* getAttributes()
SgBasicBlock* getBody()
bool isPrivate()
bool isPublic()
bool is Sequence()
SgUseStatement
// Fortran 90 module usage statements
SgSymbol moduleName
SgExpression renameList
SgStatement scope
SgMiscellaniousStatement
// Fortran 90 "contains" statements, "private" statements, and "sequence" statements
SgLogicalIfStatement
// Fortran logical if statement
SgIfElseIfStatement
// Fortran if ... then ... elseif statements
SgArithmeticIfStatement
// Fortran arithmetic if statements
SgWhereStatement
// Fortran where statement
SgWhereBlockStatement
// Fortran where ... elsewhere statement
SgAssignmentStatement
// Fortran assignment statements
SgExpression* lhs
SgExpression* rhs
SgPointerAssignmentStatement
// Fortran pointer assignment statement
SgHeapStatement
// Fortran allocate and deallocate
SgNullifyStatement
// Fortran pointer initialization statement
SgLabelListStatement
// Fortran statements containing lists of labels
SgAssignedGotoStatement
// Fortran assigned goto statement
SgComputedGotoStatement
// Fortran computed goto statement
SgStopOrPauseStatement
// Fortran stop statement
SgCallStatement
// Fortan call statement
SgIOStatement
// Fortran input/output and their control statements
SgInputOutputStatement
// Fortran read, write, and print statements
SgIOControlStatement
// Fortran open, close, inquire, backspace, rewind, endfile, and format statements
SgCycleStatement
// Fortran cycle statement
SgExitStatement
// Fortran exit statement
SgSubscriptExpression
// Fortran array references of the form lowerBound:upperBound:stride
SgKeywordValueExpression
// Fortran keyword values in I/O statements, etc.
SgReferenceExpression
// Fortran const references, type references, and interface references
SgVectorConstantExpression
// Fortran vector constants of the form [expr1,expr2,expr3]
SgObjectListExpression
// Fortran equivalence, namelist, and common statements
SgSpecPairExpression
// Fortran default control arguments to I/O statements
SgIOAccessExpressions
// Fortran index variable bound instantiations and do loop range representions
SgImplicitTypeExpression
// Fortran index variable bound instantiations
SgTypeExpression
// Fortran type expressions
SgSequenceStatement
// Fortran seq expressions
SgStringLengthExpression
// Fortran string length expressions
SgDefaultExpression
// Fortran default
SgLabelReferenceExpression
// Fortran label reference
SgConstantExpression
// Fortran array constants
SgStructureConstructorExpression
// Fortran structure constructor
SgAttributeExpression
// Fortran attributes
SgKeywordArgumentExpression
// Fortran keyword arguments
SgUseOnlyExpression
// Fortran ONLY attribute of USE statements
SgUseRenameExpression
// Fortran USE statement renamings
SgLabelVariableSymbol
// Fortran symbols for label variable for assigned goto statements
SgExternalSymbol
// Fortran symbols for external functions
SgContructSymbol
// Fortran symbols for construct names
SgModuleSymbol
// Fortran symbols for module statements
SgInterfaceSymbol
// Fortran symbols for module interface statements
B. Common IR nodes (between C,C++,F90)
These nodes would be shared between C++ and F90 (it is not yet complete)
SgNode
SgLocatedNode
SgStatement
SgDeclarationStatement
SgVariableDeclararionStatement
SgDoWhileStatement
SgIfStatement
SgSwitchStatement
SgExpressionStatement
SgContinueStatement
SgReturnStatement
SgGotoStatement
SgExpression
SgValueExpression
SgFunctionReferenceExpression
SgFunctionCallExpression
SgExpressionListExpression
SgVariableReferenceExpression
SgArrayReferenceExpression
SgInitializedNameList
SgUnaryExpression
SgBinaryExpression
SgSymbol
SgVariableSymbol
SgConstantSymbol
SgFunctionSymbol
SgType
SgArrayType
SgClassType
SgFunctionType
SgSupport
SgModifierNodes
********************************************************************************