AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Subsume se1/7/2024 Technically this should all be allowable, though. Furthermore, there are odd situations that may arise if certain annotations incorrectly modify (or delete) top-level, Driver-like annotations (like directories or output filenames). The major downside of this is that this may not be doable in a way that avoids a simultaneous refactor of Chisel's options manager. This seems intuitive to me and perhaps the direction that was thinking with the annotations refactor (or this may have been brought up and discussed before). Note: the ability of reflection to adequately do this has not been verified on my part, yet. You then get some nice magic in that all the external libraries that may be used are then automatically included in command line parsing. The job of the options manager is then to use reflection to find all annotations that exist or all annotations that have the CLI options trait and running their methods to generate help text and parse everything. Here, there's nothing that precludes forcing annotations to expose what options they take or using a trait that gets mixed into annotations (e.g., HasCommandLineOptions). While not insurmountable, this gets complicated if I"m combining several FIRRTL libraries together and want to run all their transforms. The current approach to doing this would seem to be to define my own options manager. Unifying on one (assumedly annotations) then means that everything that needs this information is passed along with the only thing that matters, the Circuit state.ĭifficulties in adding command line options for external transforms: If I go and build an external library that adds annotations and transforms, it would be great if I can hack these directly into the command line option parsing providing by the current options manager. The ability to define both "top level options" (e.g., CommonOptions) as well as NoTargetAnnotations seems particularly kludgy. These either target nothing ( NoTargetAnnotation) or some named component ( SingleTargetAnnotation) or, assumedly, some to-be-defined multiple components (a not-yet-implemented MultiTargetAnnotation). Options: All options are just annotations. However, there are two oddities here that make things somewhat incongruent now that the annotations refactor is in place and lacking in extensibility once new, custom annotations/transforms are added: Providing lightweight shims to generate annotations either indirectly with the help of the Driver (e.g., noDCE) or directly in the options manager (e.g., inline).Maintaining Driver-level information, e.g., the input file name ( inputFileNameOverride for FirrltExecutionOptions).(Note: this may be me either not realizing that I'm parroting what was being said or that this may have been discussed before.)īasically, command line options are annotations and with the maturity of the annotations refactor it makes sense to have a discussion about whether ExecutionOptionsManager is needed in its current capacity.Ĭurrently, ExecutionsOptionsManager is serving two purposes: After thinking more about comments related to command line options as "that's just an annotation", I think I have an idea on how the options and annotations can be better unified.
0 Comments
Read More
Leave a Reply. |