aaron.ballman added a comment. In D125723#3553705 <https://reviews.llvm.org/D125723#3553705>, @rnk wrote:
> In D125723#3553664 <https://reviews.llvm.org/D125723#3553664>, @aaron.ballman > wrote: > >> In D125723#3550956 <https://reviews.llvm.org/D125723#3550956>, @steplong >> wrote: >> >>> Appreciate the help! It's not clear to me how to go from the strings "Os", >>> "foo1", "foo2", "foo3" to adding "-Os -ffoo1 -ffoo2 -ffoo3" to the >>> compilation line for that function >> >> I may be misunderstanding the issue here, but what I had envisioned was that >> the `OptimizeAttr` would take either a string or integer argument (I don't >> know how easy that will be to model in Attr.td, FWIW; it may require adding >> a new kind of `Argument` for attributes) and then add a "fake" `Argument` or >> use the `AdditionalMembers` field to add a member that stores the converted >> "value" of that string or integer in whatever form makes the most sense for >> the semantics (I was envisioning an enumeration for the various kinds of >> optimization options, but maybe that doesn't work for the -f arguments?). >> Then, when doing CodeGen, you can look at the function to see if it has an >> `OptimizeAttr`, and if it does, use the fake/additional member to determine >> what information to lower to IR (or not lower, as the case may be). Does >> that help get you unstuck somewhat? >> >> Btw, one possibility would be to not support any -f flags initially and only >> support optimization levels, if that's easier. We can add support for >> individual flags at a later step but still get utility out of the attribute >> this way. > > I would really like to limit the scope here to foreclose any future > possibility of sending attribute strings through the command line parser. > That would expose a big, general API surface, with lots of possibilities for > confusing interactions with other features. Agreed. > I think it will be cleaner to keep the attributes as close as possible to > simple booleans, which then correspond relatively directly to the LLVM IR > `optnone`, `optsize`, etc attributes. Also agreed. One thing I was double-checking and am 99% sure of is that we basically can't support those -f options in Clang anyway and so we likely just want to eat them (silently so we don't cause issues when cross compiling with GCC?). Clang does not have a mapping between -O flags and -f flags in the same way that GCC does. Also, it's not clear to me that there's always a way to specify the -f flag effects for only a single function. Given that GCC documents the `optimize` attribute as "The optimize attribute should be used for debugging purposes only. It is not suitable in production code.", I think it's reasonable just to punt on -f flags entirely. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125723/new/ https://reviews.llvm.org/D125723 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
