jozefl added a comment. Now that I am in the process of implementing the processing of the "CPU" feature, I've realized the decision to store the CPU and HWMult information as enums instead of strings has some downsides that may outweigh the benefits:
- All string values passed to options need to be first converted to enums before they can be processed - Enums need to be converted back to strings in for use in diagnostics - Additional code is required to perform these conversions If all CPU and HWMult features are stored as strings, no conversions are necessary, and the overall amount of code that needs to change for this MCU data update is small. As mentioned in the original commit message, the benefits of using enums are that we have a canonical "invalid" value for when the user input is invalid, and the hard-coded data is guaranteed to be valid (but not necessarily correct) since all enums used to define features must be defined. The processing of the CPU feature is much simpler than the hwmult features, which is why all the conversions to and from enums seem even more unnecessary now. What do you think @asl? Should I get rid of the enums? That is was I'm leaning towards right now. Thanks, Jozef Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108301/new/ https://reviews.llvm.org/D108301 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits