Differences

This shows you the differences between two versions of the page.

--- spo600:2024_summer_project [2024/06/06 15:23] – chris
+++ spo600:2024_summer_project [2024/08/19 07:14] (current) – chris
@@ Line 105: / Line 105: @@
 ==== Tasks ====
+See also the [[SPO600 2024 Summer Participants]] page.
 ^ # ^ Name ^ Description ^ Notes ^ Lead ^
@@ Line 113: / Line 115: @@
 | 5 | Prune Cloned Functions (1)| Remove any AFMV-created clone functions that do not provide any significant benefit or differentiation - Task 1: determine which function(s) to prune. | | Sangwoo Shin |
 | 6 | Prune Cloned Functions (2) | Remove any AFMV-created clone functions that do not provide any significant benefit or differentiation - Perform function pruning. | | Wai Hing William Tse |
-| 7 | Diagnostic Output | Provide diagnostic output (when activated by -fdump-...-... command-line options). |  | |
+| 7 | Diagnostic Output | Provide diagnostic output (when activated by -fdump-...-... command-line options). |  | Anatolii Hryhorzhevskyi |
 | 8 | Git Wrangler | Mangage the repository. | This task includes rebasing as upstream changes and managing code reviews. | Rigels Hasani |
-| 9 | Update Documentation 1| Update the existing GCC IFUNC and FMV documentation (all archs) | Technical writing. | Shubh Janis |
+| 9 | Update Documentation 1| Update the existing GCC IFUNC and FMV documentation (all archs) | Technical writing. | Shubh Jani |
 | 10 | Create AFMV Documentation | Create documentation for the AFMV feature. | Technical writing. | Humaira Shaikh |
-| 11 | Create Tests | Create a suite of tests for the AFMV capability. (This is in addition to individual tests that the various task owners will prepare). | Requires understanding the existing test framework and writing tests. | |
+| 11 | Create Tests | Create a suite of tests for the AFMV capability. (This is in addition to individual tests that the various task owners will prepare). | Requires understanding the existing test framework and writing tests. | Zijun Li |
 | 12 | Test AFMV Implementation | Use the existing test suite(s) to verify that the aarch64 changes are not introducing regressions on aarch64 or x86-64. | Requires understanding and using the existing test framework; may involve scripting. | |
-==== What's Needed ====
+==== What You Need to Do ====
-Make as much progress on the task identified above as possible!
+Make as much progress on the task identified above as possible! The goal is to have a proof-of-concept implemention.
 Isolate your task from the other tasks. For example, if your code depends on command-line arguments, __do not__ wait for the argument parsing task to be completed - instead, you can hard-code some assumed command-line arguments for testing purposes. We'll connect the various tasks together in the next Stage of the project.
 Be sure to commit & push your code into a branch of the class GitHub repository.
+Follow the GCC project's coding standards and practices.
+==== Information about Writing Messages ====
+If you are outputting information to the user (such as warnings or error messages), here is some additional information which may be useful:
+=== gettext ===
+Throughout the GCC code, you will see strings wrapped with a function named with an underscore, like this: ''_("message")''. For example, line 3730 of ''gcc/gcc.cc'':
+  printf (_("Usage: %s [options] file...\n"), progname);
+Or line 2004 of ''gcc/opts.cc'':
+  description = _("The following options are target specific");
+This unusual syntax is part of the gettext framework, which is a core part of the internationalization (i18n) code in GCC, which is the infrastructure which enables localization (l10n) -- the ability to localize the software for use with varying languages (message text, language direction) and formats for numbers, dates, times, and currencies.
+For more information, see the [[https://www.gnu.org/software/gettext/manual/html_node/index.html|documentation for gettext]].
+However, it is sufficient in most cases to simply ensure that every string literal is wrapped in the underscore function; the i18n tools will take care of most of the rest.
+=== User Experience ===
+For advice on writing good messages (diagnostics, warnings, errors), see the [[https://gcc.gnu.org/onlinedocs/gccint/User-Experience-Guidelines.html|User Experience Guidelines]] chapter of the [[https://gcc.gnu.org/onlinedocs/gccint|GCC Internals]] documentation.
 ==== Previous Work ====
@@ Line 144: / Line 171: @@
 ==== Due Date ====
-  * June 14 for Stage 2
+  * June 15 for Stage 2
+===== Project Stage 3: Integrate, Tidy, & Wrap =====
+==== What You Need to Do ====
+Wrap up your project:
+  * Deal with any loose ends from Stage 2
+  * Integrate your code with any related code
+  * Test and document what you've done
+The goal is to get a working proof-of-concept of the GCC AFMV feature; please keep this in mind as you prioritize your work!
+[[https://github.com/seneca-cdot/gcc|Class code repository]]:
+  * Minimum: your branch must include your code
+  * Target: your code is merged with the other compatible branches and is available in the master branch of the Git repository
+This is a summary of the discussion that took place in the June 17th class regarding status and next steps for each task:
+^^#^Name^Lead^Status^Consumer (tasks we get data from)^Provider (tasks we give data to)^Affects (tasks affected)^Next Steps - Development^Next Steps - Connecting Code / Integrating^Description^$
+||1|Command-line Parsing|Marco Siu|Working for 4 values (sve, sve2, simd, neon)| | 3, 4, 7?, 11|10|Validate all target_clone options|Feed values to 3,4,7?,11 - Initializes afmv_targets array and afmv_cnt?|Parse the GCC command line to pick up AFMV options, process the version list to validate the architectural feature specification|$
+||2|arch= Arguments|Connor Squires|Picking up the values but not validating| | |1, 10|Get working target_clone| | The current GCC AArch64 FMV capability accepts versions that are identified by feature flags (such as “sve2”) but does not accept “arch=” arguments such as “arch=armv9-a” (those type of arguments are accepted by the x86 FMV implementation). Add this functionality.|$
+||3|Apply FMV cloning to functions automatically|Yukti Manoj Mulani|Throwing error msgs re target value|1|5| | Resolve error msgs|Accept data from 1|When the appropriate command-line options are provided, the compiler should automatically clone all functions, as if the target_clone attribute was specified.|$
+||4|Error message: AFMV && FMV|Mara Perkons|Working with dummy afmv arg|1| | | | Accept data from 1|Produce an error if the compiler is invoked with AFMV command-line options and there are FMV attributes specified in the code.|$
+||5|Prune Cloned Functions (1) - detect|Sangwoo Shin|???|(1), (3)|6| | | | Remove any AFMV-created clone functions that do not provide any significant benefit or differentiation - Task 1: determine which function(s) to prune.|$
+||6|Prune Cloned Functions (2) - perform prune|Wai Hing William Tse|Accepts array of function names & prunes, tests failed|5| | 7|Get tests passing| | Remove any AFMV-created clone functions that do not provide any significant benefit or differentiation - Perform function pruning.|$
+||7|Diagnostic Output|Anatolii Hryhorzhevskyi|Not dumping |6| | |Get dumps working|Integrate into 6|Provide diagnostic output (when activated by -fdump-…-… command-line options).|$
+||8|Git Wrangler|Rigels Hasani|5 branches updated| | | | Rebase|Merge|Mangage the repository.|$
+||9|Update Documentation 1|Shubh Janis|???|-2| | |(Complete)| | Update the existing GCC IFUNC and FMV documentation (all archs)|$
+||10|Create AFMV Documentation|Humaira Shaikh|???|(*, 1, 2, 4, 7)| | |Update with code changes| | Create documentation for the AFMV feature.|$
+||11|Create Tests|Zijun Li|???|1, (2?), 4, (5/6?), 7)| | |Update with code changes| | Create a suite of tests for the AFMV capability. (This is in addition to individual tests that the various task owners will prepare).|$
+||12|Test AFMV Implementation| | | | | | | | Use the existing test suite(s) to verify that the aarch64 changes are not introducing regressions on aarch64 or x86-64.|$
+=== Blogging ===
+  * Provide an overview of the final state of your project code:
+    * Location in class Git repository (branch)
+    * Integration with other branches
+    * What works, what limitations exist, what doesn't work, and what is not tested
+  * Provide detailed reflections on the project work and the course
+==== Due Date ====
+  * June 21 for Stage 3