aaron.ballman added a comment.
In D126984#3574445 <https://reviews.llvm.org/D126984#3574445>, @xbolva00 wrote:
> "The optimize attribute should be used for debugging purposes only. It is not
> suitable in production code."
>
> Until they (users) start and any change in pipeline may surprise them.
Too bad for them? I guess my sympathy button is broken for users who use things
in production code that are documented as not being suitable for production
code. :-D
> Personally I am bigger fan of more targeted attributes like we have noinline
> / noipa proposed but stalled / and then we could have new ones to disable
> vectorizers, LICM, unroller, etc..
>
> Yes, we could claim that attribute((optimize("-fno-slp-vectorize") then maps
> exactly to attribute((noslp)).
>
> Still, I would like to hear some motivation words other than "gcc" has it.
What I want to avoid is the continued proliferation of semantic attributes
related to optimizations that are otherwise controlled by command line flags.
We have optnone, minsize, Stephen's original patch for the MSVC pragma added
another one, you're talking about adding optsize, etc. All of these are
semantically doing "the same thing", which is associating some coarse
granularity optimization hints with a function definition that would otherwise
be even more coarsely controlled via the command line. Having multiple semantic
attributes makes supporting this more fragile because everywhere that wants to
care about coarse-grained optimizations has to handle the combinatorial matrix
of ways they can be mixed together and as that grows, we will invariably get it
wrong by forgetting something.
What I don't have a strong opinion on is what attributes we surface to users so
they can spell them in their source. I have no problem exposing GCC's
attributes, and MSVC's attributes, and our own attributes in whatever fun
combinations we want to allow. What I want is that all of those related
attributes are semantically modeled via ONE attribute in the AST. When
converting these parsed optimization attributes into semantic attributes, I
want us to map whatever information is in the parsed attribute onto that single
semantic attribute. When we merge attributes on a declaration, I want that one
attribute to be updated instead of duplicated with different values. So at the
end of the day, when we get to CodeGen, we can query for the one attribute and
its semantic effects instead of querying for numerous attributes and trying to
decide what to do when more than one attribute is present at that point.
That's why I pushed Stephen to make this patch. The fact that it also happens
to expose a feature from GCC that is very closely related to what he's trying
to do for the MSVC pragma was a nice added bonus.
This leaves a few questions:
1. Are you opposed to exposing #pragma optimize?
(https://docs.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170) If
yes, I think Stephen should run an RFC on Discourse to see if there's general
agreement.
2. Are you opposed to the direction of condensing the optimization semantic
attributes (the things in the AST) down into one? If yes, I'd like to
understand why better.
3. Are you still opposed to exposing a neutered form of the GCC optimize
attribute as a parsed attribute (the thing users write in their source)? If
yes, that's fine by me, but then I'd still like to see most of this patch land,
just without a way for the user to spell the attribute themselves. We can
adjust the semantic attribute's enumeration to cover only the cases we want to
support.
4. Or are you opposed to the notion of having one semantic attribute to control
all of this and you prefer to see multiple individual semantic attributes and
all that comes along with them in terms of combinations?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126984/new/
https://reviews.llvm.org/D126984
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
