[clang] Add support for optimize function attribute

[steplong]

Summary

This attribute is similar to GCC's function attribute, but it doesn't support
compiling functions with arbitrary optimization options. This patch only
supports "-Os", "-Oz", "-Ofast", "-O0" because they map to existing
attributes cleanly. We don't intend to support arbitrary options, like GCC,
with this attribute.

i.e. __attribute__((optimize("O0")))

[steplong]

clang/lib/CodeGen/CGCall.cpp

2169

I don't think this is the most ergonomic way. Let me know if you have a better idea of doing this

[aaron.ballman]

clang/include/clang/Basic/Attr.td

2265

Something along these lines adds a "fake" argument to the attribute. This means the parsed attribute doesn't care about this argument (so users don't supply it when writing the attribute themselves), but the semantic attribute (OptimizeAttr) will have a member to track the fake argument value and will require extra information when creating the attribute.

This effectively will add:

enum OptLevelKind {
  O0,
  O1,
  O2,
  O3,
  O4
} OptLevel;

to the semantic attribute.

2267

You should add some rudimentary documentation for this, and probably point to the GCC docs for further information.

clang/include/clang/Basic/DiagnosticSemaKinds.td

3019–3020

I'm not 100% in love with the list of valid options in my suggested wording (I had originally listed the valid values manually and that was not much better).

One thing I think is important is that this be a warning rather than an error. Users will pass "-f" strings here which are supported by GCC; they should just be able to ignore the warning in Clang as being harmless, but if it's an error, the user has to change the function signatures in ways that are kind of annoying.

clang/lib/CodeGen/CGCall.cpp

2169

I'll sprinkle some comments around about how I'd investigate handling this.

Based on those suggestions, here you would be able to ask for OptimizeAttr->getOptLevel() and it will return the mapped enumeration value, which should clean this code up to not require string checking.

Btw, hasAttr() followed by getAttr() is generally a code smell (same smell as isa followed by cast). You should switch to logic more like:

if (const auto *OA = TargetDecl->getAttr<OptimizeAttr>()) {

}

so that we only have to traverse the list of attributes once instead of twice.

2171–2172

I think we also need to check for -Ofast, -Oz, and -Og (https://github.com/llvm/llvm-project/blob/main/clang/lib/Frontend/CompilerInvocation.cpp#L575)

clang/lib/Sema/SemaDeclAttr.cpp

4841–4850

Then, in here, you can parse the -O<whatever> the user passed as a string, and convert it to an OptimizeAttr::OptLevelKind enumerator and store that in the semantic attribute.

This allows you to map things like -Og to whatever -O level that actually represents, or do any other kind of mapping that works for you.

One question we should probably figure out is whether we also want to support clang-cl optimization strings or not. e.g., __attribute__((optimize("/O0"))) with a slash instead of a dash. Since we're already going to be doing parsing from here anyway, I feel like it might not be a bad idea to also support those. FWIW, here's the list from the user's manual:

/O0                     Disable optimization
/O1                     Optimize for size  (same as /Og     /Os /Oy /Ob2 /GF /Gy)
/O2                     Optimize for speed (same as /Og /Oi /Ot /Oy /Ob2 /GF /Gy)
/Ob0                    Disable function inlining
/Ob1                    Only inline functions which are (explicitly or implicitly) marked inline
/Ob2                    Inline functions as deemed beneficial by the compiler
/Od                     Disable optimization
/Og                     No effect
/Oi-                    Disable use of builtin functions
/Oi                     Enable use of builtin functions
/Os                     Optimize for size
/Ot                     Optimize for speed
/Ox                     Deprecated (same as /Og /Oi /Ot /Oy /Ob2); use /O2 instead
/Oy-                    Disable frame pointer omission (x86 only, default)
/Oy                     Enable frame pointer omission (x86 only)
/O<flags>               Set multiple /O flags at once; e.g. '/O2y-' for '/O2 /Oy-'

(Not all of these would be supported, like enable use of builtin functions, etc.) WDYT?

[steplong]

• Added docs for attribute
• Changed attribute to use Enum
• Optsize includes -Og, -Oz, and -Ofast
• Change to warning instead of error

[steplong]

clang/lib/Sema/SemaDeclAttr.cpp

4841–4850

Hmm I don't think it's necessary to get pragma optimize to work, but it shouldn't be hard to add the parsing logic for some of these strings

[aaron.ballman]

I think this is getting close -- mostly just nits at this point.

clang/include/clang/Basic/AttrDocs.td

3463

3465–3467

clang/lib/CodeGen/CodeGenModule.cpp

1932–1934

Coding style nit.

clang/lib/Sema/SemaDeclAttr.cpp

4841–4850

Definitely agreed on the MSVC command line switches, so if those are a burden, feel free to skip them. For the other flags, those seem more important to support because they're also flags present in GCC so users are more likely to expect them to work.

4850

Given that most of the strings we're dealing with are either literals or a StringRef, I think you should use llvm:: StringMap instead of unordered_map. (We tend to avoid STL containers because their performance characteristics are often different than what we need as a compiler.)

4858

Probably meant to remove this?

4868

[steplong]

• Fix up docs and comments
• Fix failing pragma-attribute-supported-attributes-list.test
• Remove debug print
• Change to StringMap

[aaron.ballman]

Two final (I hope) nits! One is in the code, the other is that this should have a release note for the new attribute. Assuming precommit CI pipeline passes, then I think this is all set.

clang/lib/Sema/SemaDeclAttr.cpp

4860

Sorry for missing this before, but on both of the calls to Create here, you should be passing in Arg so that the AST retains full source fidelity (this matters for things like pretty printing).

[steplong]

• Add Arg when creating Attr

[steplong]

In D126984#3567822, @aaron.ballman wrote:

Two final (I hope) nits! One is in the code, the other is that this should have a release note for the new attribute. Assuming precommit CI pipeline passes, then I think this is all set.

Haha, no worries! I appreciate the review

[aaron.ballman]

LGTM, but please add the release note when landing. Thanks!

[steplong]

• Added release notes on attribute

[aeubanks]

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

[steplong]

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

Hmm, this does affect codegen, so I'm not sure if it's purely a clang frontend thing. Maybe someone else can confirm. The motivation behind this was to add support for MSVC's pragma optimize in D125723. https://docs.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170

[aaron.ballman]

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

Hmm, does the pass manager have to support anything here? The only Clang codegen changes are for emitting IR attributes that we already emitted based on command line flags/other attributes, so I had the impression this would not be invasive for the backend at all.

[aeubanks]

In D126984#3574033, @steplong wrote:

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

Hmm, this does affect codegen, so I'm not sure if it's purely a clang frontend thing. Maybe someone else can confirm. The motivation behind this was to add support for MSVC's pragma optimize in D125723. https://docs.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170

adding optsize/minsize/optnone attributes to functions is fine and is already handled in optimizations, but being able to specify -O[0-3] would require a lot of new complexity in the pass manager which would likely not be worth it
I think D125723 is fine as is

[xbolva00]

I agree with @aeubanks , this feature requires major changes to pass manager and I see no value to land this currently.

I see that somebody may prefer “opt for size”, but this is exposed via “minsize” attribute so I see no strong need for optimize(“-Os”)

[aeubanks]

In D126984#3574046, @aaron.ballman wrote:

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

Hmm, does the pass manager have to support anything here? The only Clang codegen changes are for emitting IR attributes that we already emitted based on command line flags/other attributes, so I had the impression this would not be invasive for the backend at all.

if we're allowing individual functions to specify that they want the -O1 pipeline when everything else in the module should be compiled with -O2, that's a huge change in the pass manager. but perhaps I'm misunderstanding the point of this patch

[steplong]

In D126984#3574077, @aeubanks wrote:

In D126984#3574046, @aaron.ballman wrote:

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

Hmm, does the pass manager have to support anything here? The only Clang codegen changes are for emitting IR attributes that we already emitted based on command line flags/other attributes, so I had the impression this would not be invasive for the backend at all.

if we're allowing individual functions to specify that they want the -O1 pipeline when everything else in the module should be compiled with -O2, that's a huge change in the pass manager. but perhaps I'm misunderstanding the point of this patch

That makes sense. The MSVC pragma allows 4 options, "stgy":

Parameter	On	Off
g	Deprecated	Deprecated
s	Add MinSize	Remove MinSize (I think this would be difficult to do if -Os is passed on the cmdline)
t	Add -O2 (We can't support -O2 with this attribute so ignore)	Add Optnone
y	Add frame-pointers (We can't support -f arguments with the attribute in this patch so we are ignoring this)	No frame-pointers (Same thing as on)

For our use case, I think we only really see #pragma optimize("", off) and #pragma optimize("", on), so I'm not opposed to abandoning this patch and just supporting the common use case for now. I think #pragma optimize("", on) would just mean do nothing and apply whatever is on the command line and #pragma optimize("", off) would mean add optnone to the functions below it

[aeubanks]

In D126984#3574091, @steplong wrote:

In D126984#3574077, @aeubanks wrote:

In D126984#3574046, @aaron.ballman wrote:

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

Hmm, does the pass manager have to support anything here? The only Clang codegen changes are for emitting IR attributes that we already emitted based on command line flags/other attributes, so I had the impression this would not be invasive for the backend at all.

if we're allowing individual functions to specify that they want the -O1 pipeline when everything else in the module should be compiled with -O2, that's a huge change in the pass manager. but perhaps I'm misunderstanding the point of this patch

That makes sense. The MSVC pragma allows 4 options, "stgy":

Parameter	On	Off
g	Deprecated	Deprecated
s	Add MinSize	Remove MinSize (I think this would be difficult to do if -Os is passed on the cmdline)
t	Add -O2 (We can't support -O2 with this attribute so ignore)	Add Optnone
y	Add frame-pointers (We can't support -f arguments with the attribute in this patch so we are ignoring this)	No frame-pointers (Same thing as on)

For our use case, I think we only really see #pragma optimize("", off) and #pragma optimize("", on), so I'm not opposed to abandoning this patch and just supporting the common use case for now. I think #pragma optimize("", on) would just mean do nothing and apply whatever is on the command line and #pragma optimize("", off) would mean add optnone to the functions below it

looks good to me, I agree that we should just honor whatever optimization level the file is compiled with with t

[aaron.ballman]

In D126984#3574077, @aeubanks wrote:

In D126984#3574046, @aaron.ballman wrote:

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

Hmm, does the pass manager have to support anything here? The only Clang codegen changes are for emitting IR attributes that we already emitted based on command line flags/other attributes, so I had the impression this would not be invasive for the backend at all.

if we're allowing individual functions to specify that they want the -O1 pipeline when everything else in the module should be compiled with -O2, that's a huge change in the pass manager. but perhaps I'm misunderstanding the point of this patch

I guess I'm not seeing what burden is being added here (you may still be correct though!)

The codegen changes basically boil down to:

if (!HasOptnone) {
  if (CodeGenOpts.OptimizeSize || HasOptsize) // This was updated for || HasOptsize
    FuncAttrs.addAttribute(llvm::Attribute::OptimizeForSize);
  if (CodeGenOpts.OptimizeSize == 2)
    FuncAttrs.addAttribute(llvm::Attribute::MinSize);
}

and

bool HasOptimizeAttrO0 = false;                                     // NEW
if (const auto *OA = D->getAttr<OptimizeAttr>())
  HasOptimizeAttrO0 = OA->getOptLevel() == OptimizeAttr::O0;

// Add optnone, but do so only if the function isn't always_inline.
if ((ShouldAddOptNone || D->hasAttr<OptimizeNoneAttr>() ||
     HasOptimizeAttrO0) &&                                          // NEW
    !F->hasFnAttribute(llvm::Attribute::AlwaysInline)) {
  B.addAttribute(llvm::Attribute::OptimizeNone);

For my own education, are you saying that these changes are specifying the entire -O<N> pipeline?

The patch looks for O0 in the attribute, but the other O<N> values are noops. We do some mapping though:

OptimizeAttr::OptLevelKind Kind = OA->getOptLevel();
HasOptnone = HasOptnone || (Kind == OptimizeAttr::O0);
HasOptsize = Kind == OptimizeAttr::Os || Kind == OptimizeAttr::Og ||
             Kind == OptimizeAttr::Ofast || Kind == OptimizeAttr::Oz;

but I'm failing to understand why this would be a concern for the backend given that we already support setting the LLVM IR flags based on other attributes. e.g., why is [[clang::optnone]] okay but [[gnu::optimize("O0")]] a problem?

[xbolva00]

[[gnu::optimize("O0")]] is okay but [[gnu::optimize("O3")]] is not gonna work without major changes. Not sure why we should deliver half-broken new attribute.

Some strong motivation/use cases why somebody needs to compile some functions with -O2 and some with -O3?

[xbolva00]

In D126984#3574071, @xbolva00 wrote:

I agree with @aeubanks , this feature requires major changes to pass manager and I see no value to land this currently.

I see that somebody may prefer “opt for size”, but this is exposed via “minsize” attribute so I see no strong need for optimize(“-Os”)

Hmm.. We expose minsize attribute in C, (like -Oz), but "optsize" is not exposed (like -Os). I will try to create a patch for exposing it.

[aaron.ballman]

In D126984#3574288, @xbolva00 wrote:

[[gnu::optimize("O0")]] is okay but [[gnu::optimize("O3")]] is not gonna work without major changes. Not sure why we should deliver half-broken new attribute.

I don't see it as half-broken given that it's explicitly documented by GCC as "The optimize attribute should be used for debugging purposes only. It is not suitable in production code."

Some strong motivation/use cases why somebody needs to compile some functions with -O2 and some with -O3?

This patch leaves O1-O4 as noops, and really only does anything with O0 and the letter-based ones, so I don't know that we need to do that exercise until we want to make them actually do something. Similarly, we don't allow any of the -f flags like GCC does.

I don't insist on keeping this attribute specifically, but I like the fact that it gives us *one* attribute that we can use as a basis for all these various other ways of spelling optimization hints (optnone, #pragma optimize, minsize, etc). I think I'd ultimately like to see all of those other attributes as alternate spellings of this one and they just map to the appropriate internal "level".

(I'm totally fine with us not supporting optimization hints that the backend would struggle with, this is more about how we model the notion of a per-function user-provided optimization hint without adding a new attribute every time.)

[xbolva00]

"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.

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.

[aaron.ballman]

In 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?

[aeubanks]

I can't speak for @xbolva00 but the only part I'm against is the user-visible feature of

• Added preliminary support for GCC's attribute optimize, which allows functions to be compiled with different optimization options than what was specified on the command line.

which implies that we're on the way to support per-function optimization levels (which we aren't)
the internal clang representation changes are all fine

and even for the MSVC pragma #pragma optimize("t", on), what are we supporting if the user compiles their code with -O0? because right now we won't optimize anything with -O0

[xbolva00]

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.

No, I like it, seems more useful and general than "pragma clang optimize on/off"

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.

No :)

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.

Not entirely opposed, GCC optimize attribute could partially work fine, O0 maps to optnone, Os to optsize, Oz to minsize. I am more worried about next steps, see below.

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?

Not strongly opposed, just some concerns how this could work together with LLVM. Example: attribute((optimize("-fno-licm"))) -> 'optimize="no-licm" '? This could work. Possibly also allow this form: attribute((optimize(no-licm, optsize))) ?

What about current attributes? Should/can we drop them and use for example 'optimize="no-ipa,no-clone" '? Not strongly opposed, but probably a lot of work.

But to use different pipeline for different functions (here I mean -O1, O2, O3) is a major change to LLVM pass manager and I think this use case does not justify it.

[xbolva00]

But where I think this feature could be very useful in following case from gcc test suite where there is some FP computation..
Imagine you compile you program with -ffast-math and then you have function:

__attribute__ ((optimize ("no-associative-math"))) double
fn3 (double h, double l) /* { dg-message "previous definition" } */
{
  return h + l;
}

So in this case, codegen would just drop llvm attribute "reassoc".

[xbolva00]

clang/test/CodeGen/attr-optimize.c

5

No support for

__attribute__ ((__optimize__ (0)))

? GCC supports it

[steplong]

clang/test/CodeGen/attr-optimize.c

5

Nope, I only added support for one argument and only strings. I think gcc supports expressions, multiple args, -f args, and -O args. I wasn't sure how to implement it in Attr.td without making heavy changes.

[xbolva00]

clang/test/CodeGen/attr-optimize.c

17

For -Os, clang adds optsize. For -Oz, clang adds optsize and minsize. So tests should check it, maybe currently this is broken in your patch?

https://godbolt.org/z/dEsffoeW4

[steplong]

• Add llvm::Attribute::MinSize when OptimizeAttr::Oz
• Add test for checking minsize

[aaron.ballman]

In D126984#3574550, @aeubanks wrote:

I can't speak for @xbolva00 but the only part I'm against is the user-visible feature of

• Added preliminary support for GCC's attribute optimize, which allows functions to be compiled with different optimization options than what was specified on the command line.

which implies that we're on the way to support per-function optimization levels (which we aren't)
the internal clang representation changes are all fine

Ah, would you be okay if we retained the user-facing feature but more clearly documented (in release notes and documentation) the differences from GCC and that we do not currently intend to close that gap?

and even for the MSVC pragma #pragma optimize("t", on), what are we supporting if the user compiles their code with -O0? because right now we won't optimize anything with -O0

@steplong -- what are your thoughts on this?

In D126984#3574592, @xbolva00 wrote:

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?

But to use different pipeline for different functions (here I mean -O1, O2, O3) is a major change to LLVM pass manager and I think this use case does not justify it.

Thanks for clarifying! I'd be fine changing the internal enumeration for the attribute to represent a better subset of what we intend to implement support for (rather than making it look like we intend to support O1-O4). Would that work for you (and you as well @aeubanks)?

[xbolva00]

Would that work for you (and you as well @aeubanks)?

yes :)

[steplong]

and even for the MSVC pragma #pragma optimize("t", on), what are we supporting if the user compiles their code with -O0? because right now we won't optimize anything with -O0

@steplong -- what are your thoughts on this?

Hmm, I think I'm ok with ignoring the pragma when "-O0". In the case of "t", at the moment, we are just going to honor whatever is passed on the commandline. I think with what the patch looks like now, we'll be supporting the pragma optimize like:

Parameter	On	Off
g	Deprecated	Deprecated
s	Add OptimizeAttr::Os	Add Optnone (Not sure if this makes sense)
t	Do nothing	Add Optnone
y	Do nothing	Do nothing

[aaron.ballman]

In D126984#3578950, @steplong wrote:

and even for the MSVC pragma #pragma optimize("t", on), what are we supporting if the user compiles their code with -O0? because right now we won't optimize anything with -O0

@steplong -- what are your thoughts on this?

Hmm, I think I'm ok with ignoring the pragma when "-O0". In the case of "t", at the moment, we are just going to honor whatever is passed on the commandline. I think with what the patch looks like now, we'll be supporting the pragma optimize like:

Parameter	On	Off
g	Deprecated	Deprecated
s	Add OptimizeAttr::Os	Add Optnone (Not sure if this makes sense)
t	Do nothing	Add Optnone
y	Do nothing	Do nothing

I think that works for me.

clang/docs/ReleaseNotes.rst

331–333 ↗

(On Diff #436443)

And we can clarify in the release note that we're not intending to fully support this attribute.

clang/include/clang/Basic/Attr.td

2267–2268

Assuming this also addresses @aeubanks 's concerns, I think we should remove O1 through O4 and maybe consider renaming the other enumerations to be less about the command line option and more about the effects. e.g., Fast, MinSize, NoOpts etc. We'll still do the mapping from O0 and whatnot to these values (within SemaDeclAttr.cpp) but this should hopefully clarify that the semantics we're after are not really pipeline semantics.

clang/include/clang/Basic/AttrDocs.td

3462

And we can add to the documentation that we don't intend to fully support the GCC semantics and further comment about ignoring O1 through O4, etc.

[steplong]

• Remove -Og, and all non-zero optimization levels
• Fix up docs
• Modified tests to reflect -Og and non-zero opt level change

[aeubanks]

clang/include/clang/Basic/AttrDocs.td

3469

something about optimize(-Os) still depending on the file's overall optimization level (e.g. clang -O0 won't do anything) would be good

[xbolva00]

If you compile file with -Ofast and use optimise(-Os) for F - I would expect no fast math flags for function F but I am worried a bit that only “optsize” is added and no fast math flags are removed. Plesse verify and/or add such test.

[jdoerfert]

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

We actually should *not* make this a clang frontend only thing. It is confusing and not helpful. That said, we have code to integrate this into the new PM already as we were planning on proposing something along these lines too. We didn't manage to get to it during last years GSoC but the code could be used as a basis still.

+1 for RFC
strong preference for proper integration of this into the new PM.

@tarinduj has the code in his repo, newest version, I think is: https://github.com/tarinduj/llvm-project/blob/a24b1d1b2033b6bb17b7ad1c58b15d34e078fdb8/llvm/include/llvm/IR/PassManager.h#L464

[aaron.ballman]

In D126984#3579842, @jdoerfert wrote:

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

We actually should *not* make this a clang frontend only thing. It is confusing and not helpful. That said, we have code to integrate this into the new PM already as we were planning on proposing something along these lines too. We didn't manage to get to it during last years GSoC but the code could be used as a basis still.

+1 for RFC
strong preference for proper integration of this into the new PM.

I'm not opposed to an RFC to extend this functionality, but it seems to me that we have incremental progress already with this patch and landing this patch unblocks the work @steplong was originally doing for the MSVC pragma. Do you have a concern if we move forward with this less-functional form so that work isn't held up on an RFC for the more fully functional form?

[xbolva00]

In D126984#3581708, @aaron.ballman wrote:

In D126984#3579842, @jdoerfert wrote:

In D126984#3571573, @aeubanks wrote:

IIRC in the past there was a strong preference to not have the pass manager support this sort of thing
if you want to support this, there should be an RFC for how the optimization part of this will work as it may require invasive changes to the LLVM pass manager

(if this is purely a clang frontend thing then ignore me)

We actually should *not* make this a clang frontend only thing. It is confusing and not helpful. That said, we have code to integrate this into the new PM already as we were planning on proposing something along these lines too. We didn't manage to get to it during last years GSoC but the code could be used as a basis still.

+1 for RFC
strong preference for proper integration of this into the new PM.

I'm not opposed to an RFC to extend this functionality, but it seems to me that we have incremental progress already with this patch and landing this patch unblocks the work @steplong was originally doing for the MSVC pragma. Do you have a concern if we move forward with this less-functional form so that work isn't held up on an RFC for the more fully functional form?

I was thinking about this again and I am more and more unsure about this feature. -Os/-Oz is something more than just some attribute.

Look here: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp and see lines (conditions) with SizeLevel and OptLevel.

[aaron.ballman]

In D126984#3581829, @xbolva00 wrote:

I was thinking about this again and I am more and more unsure about this feature. -Os/-Oz is something more than just some attribute.

That's not stopped us from exposing attributes like minsize (and you proposed optsize as well) which get described in the same terms as -Os/-Oz in our documentation, so this ship has somewhat sailed.

(FWIW, I don't have a strong opinion on the attributes we expose here. I do have strong opinions about increasing the maintenance burdens by adding more related attributes without carefully considering their semantic and code gen interactions.)

[xbolva00]

That's not stopped us from exposing attributes like minsize (and you proposed optsize as well) which get described in the same terms as -Os/-Oz in our documentation, so this ship has somewhat sailed.

Well, there is no promise that attribute matches -O flag in the documentation, indeed. But I understand your point and not a issue in practise.

Look here: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp and see lines (conditions) with SizeLevel and OptLevel.

Second look, I think it is possible to rework those lines to respect attributes more; like for example

MPM.add(createLoopRotatePass(SizeLevel == 2 ? 0 : -1, PrepareForLTO));

in such way, that in the pass itself, we would do something like OptionXYZ = F.isMinSize() ? 0 : -1;

[steplong]

I'm open to tabling this and just implementing support for an empty optimization list for the pragma (i.e. #pragma optimize("", on | off)). For our use case, at the moment, we only see the pragma being used this way. on would be a noop (honor command-line) and off would mean add optnone to the functions below the pragma

[aaron.ballman]

In D126984#3582508, @steplong wrote:

I'm open to tabling this and just implementing support for an empty optimization list for the pragma (i.e. #pragma optimize("", on | off)). For our use case, at the moment, we only see the pragma being used this way. on would be a noop (honor command-line) and off would mean add optnone to the functions below the pragma

If that meets your needs, that is certainly a way to get you unblocked. I'm fine with that approach if you are.

I appreciate your patience while we figure out the right approach here; we don't usually have this many false starts when working through a feature review. :-)

[steplong]

I appreciate your patience while we figure out the right approach here; we don't usually have this many false starts when working through a feature review. :-)

No worries, I appreciate the community doing the due diligence.

[xbolva00]

Also note that there is a '#pragma GCC optimize' pragma. After this patch, it should not be hard to implement it.

https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html

[jdoerfert]

FWIW, I think we should have these attributes as spelled here, just w/ proper pass manager integration which then requires an RFC.
That said, I'm not opposed to this as an incremental step, albeit confusing until the PM support is integrated if we allow O1/2/3/fast

clang/include/clang/Basic/Attr.td

 }
 
 def OptimizeNone : InheritableAttr {
   let Spellings = [Clang<"optnone">];
   let Subjects = SubjectList<[Function, ObjCMethod]>;
   let Documentation = [OptnoneDocs];
 }
 
+def Optimize : InheritableAttr {
+  let Spellings = [GCC<"optimize">];
+  let Args = [StringArgument<"Level">,
+              EnumArgument<"OptLevel", "OptLevelKind",
+                           ["Ofast", "Og", "Oz", "Os", "O0", "O1", "O2", "O3", "O4"],
+                           ["Ofast", "Og", "Oz", "Os", "O0", "O1", "O2", "O3", "O4"],
+                           /*optional*/0, /*fake*/1>];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [OptimizeDocs];
+}
+
 def Overloadable : Attr {
   let Spellings = [Clang<"overloadable">];
   let Subjects = SubjectList<[Function], ErrorDiag>;
   let Documentation = [OverloadableDocs];
   let SimpleHandler = 1;
 }
 
 def Override : InheritableAttr {

clang/include/clang/Basic/AttrDocs.td

 specified function can improve the quality of the debugging information
 for that function.
 
 This attribute is incompatible with the ``always_inline`` and ``minsize``
 attributes.
   }];
 }
 
+def OptimizeDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``optimize`` attribute, when attached to a function, indicates that the
+function should be compiled with a different optimization level than specified
+on the command line. See the Function Attributes documentation on GCC's docs for
+more information. Currently, the attribute differs from GCC in that Clang only
+supports one argument, doesn't support ``-f`` arguments, and also doesn't
+support expressions or integers as arguments.
+
+Refer to: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
+  }];
+}
+
 def LoopHintDocs : Documentation {
   let Category = DocCatStmt;
   let Heading = "#pragma clang loop";
   let Content = [{
 The ``#pragma clang loop`` directive allows loop optimization hints to be
 specified for the subsequent loop. The directive allows pipelining to be
 disabled, or vectorization, vector predication, interleaving, and unrolling to
 be enabled or disabled. Vector width, vector predication, interleave count,

clang/include/clang/Basic/DiagnosticSemaKinds.td

 def err_attribute_parameter_types : Error<
   "%0 attribute parameter types do not match: parameter %1 of function %2 has type %3, "
   "but parameter %4 of function %5 has type %6">;
 
 def err_attribute_too_many_arguments : Error<
   "%0 attribute takes no more than %1 argument%s1">;
 def err_attribute_too_few_arguments : Error<
   "%0 attribute takes at least %1 argument%s1">;
+def warn_invalid_optimize_attr_level : Warning <
+   "invalid optimization level '%0' specified; the argument to '-O' should be a non-negative integer, "
+   "'-Os', '-Oz', '-Og', or '-Ofast'; attribute ignored">,
+   InGroup<IgnoredAttributes>;
 def err_attribute_invalid_vector_type : Error<"invalid vector element type %0">;
 def err_attribute_invalid_matrix_type : Error<"invalid matrix element type %0">;
 def err_attribute_bad_neon_vector_size : Error<
   "Neon vector size must be 64 or 128 bits">;
 def err_attribute_invalid_sve_type : Error<
   "%0 attribute applied to non-SVE type %1">;
 def err_attribute_bad_sve_vector_size : Error<
   "invalid SVE vector size '%0', must match value set by "

clang/lib/CodeGen/CGCall.cpp

if (const RecordType *RT =
     if (const auto *ClassDecl = dyn_cast<CXXRecordDecl>(RT->getDecl()))
       return ClassDecl->hasTrivialDestructor();
   }
   return ReturnType.isTriviallyCopyableType(Context);
 }
 
 void CodeGenModule::getDefaultFunctionAttributes(StringRef Name,
                                                  bool HasOptnone,
+                                                 bool HasOptsize,
                                                  bool AttrOnCallSite,
                                                  llvm::AttrBuilder &FuncAttrs) {
   // OptimizeNoneAttr takes precedence over -Os or -Oz. No warning needed.
   if (!HasOptnone) {
-    if (CodeGenOpts.OptimizeSize)
+    if (CodeGenOpts.OptimizeSize || HasOptsize)
       FuncAttrs.addAttribute(llvm::Attribute::OptimizeForSize);
     if (CodeGenOpts.OptimizeSize == 2)
       FuncAttrs.addAttribute(llvm::Attribute::MinSize);
   }
 
   if (CodeGenOpts.DisableRedZone)
     FuncAttrs.addAttribute(llvm::Attribute::NoRedZone);
   if (CodeGenOpts.IndirectTlsSegRefs)
for (StringRef Attr : CodeGenOpts.DefaultFunctionAttrs) {
     StringRef Var, Value;
     std::tie(Var, Value) = Attr.split('=');
     FuncAttrs.addAttribute(Var, Value);
   }
 }
 
 void CodeGenModule::addDefaultFunctionDefinitionAttributes(llvm::Function &F) {
   llvm::AttrBuilder FuncAttrs(F.getContext());
-  getDefaultFunctionAttributes(F.getName(), F.hasOptNone(),
+  getDefaultFunctionAttributes(F.getName(), F.hasOptNone(), F.hasOptSize(),
                                /* AttrOnCallSite = */ false, FuncAttrs);
   // TODO: call GetCPUAndFeaturesAttributes?
   F.addFnAttrs(FuncAttrs);
 }
 
 void CodeGenModule::addDefaultFunctionDefinitionAttributes(
                                                    llvm::AttrBuilder &attrs) {
   getDefaultFunctionAttributes(/*function name*/ "", /*optnone*/ false,
-                               /*for call*/ false, attrs);
+                               /*optsize*/ false, /*for call*/ false, attrs);
   GetCPUAndFeaturesAttributes(GlobalDecl(), attrs);
 }
 
 static void addNoBuiltinAttributes(llvm::AttrBuilder &FuncAttrs,
                                    const LangOptions &LangOpts,
                                    const NoBuiltinAttr *NBA = nullptr) {
   auto AddNoBuiltinAttr = [&FuncAttrs](StringRef BuiltinName) {
     SmallString<32> AttributeName;
void CodeGenModule::ConstructAttributeList(StringRef Name,
 
   const Decl *TargetDecl = CalleeInfo.getCalleeDecl().getDecl();
 
   // Attach assumption attributes to the declaration. If this is a call
   // site, attach assumptions from the caller to the call as well.
   AddAttributesFromAssumes(FuncAttrs, TargetDecl);
 
   bool HasOptnone = false;
+  bool HasOptsize = false;
   // The NoBuiltinAttr attached to the target FunctionDecl.
   const NoBuiltinAttr *NBA = nullptr;
 
   // Collect function IR attributes based on declaration-specific
   // information.
   // FIXME: handle sseregparm someday...
   if (TargetDecl) {
     if (TargetDecl->hasAttr<ReturnsTwiceAttr>())
if (TargetDecl) {
     if (TargetDecl->hasAttr<AnyX86NoCallerSavedRegistersAttr>())
       FuncAttrs.addAttribute("no_caller_saved_registers");
     if (TargetDecl->hasAttr<AnyX86NoCfCheckAttr>())
       FuncAttrs.addAttribute(llvm::Attribute::NoCfCheck);
     if (TargetDecl->hasAttr<LeafAttr>())
       FuncAttrs.addAttribute(llvm::Attribute::NoCallback);
 
     HasOptnone = TargetDecl->hasAttr<OptimizeNoneAttr>();
+    if (const auto *OA = TargetDecl->getAttr<OptimizeAttr>()) {
+      OptimizeAttr::OptLevelKind Kind = OA->getOptLevel();
+      HasOptnone = HasOptnone || (Kind == OptimizeAttr::O0);
+      HasOptsize = Kind == OptimizeAttr::Os || Kind == OptimizeAttr::Og ||
+                   Kind == OptimizeAttr::Ofast || Kind == OptimizeAttr::Oz;
+    }
     if (auto *AllocSize = TargetDecl->getAttr<AllocSizeAttr>()) {
       Optional<unsigned> NumElemsParam;
       if (AllocSize->getNumElemsParam().isValid())
         NumElemsParam = AllocSize->getNumElemsParam().getLLVMIndex();
       FuncAttrs.addAllocSizeAttr(AllocSize->getElemSizeParam().getLLVMIndex(),
                                  NumElemsParam);
     }
 
void CodeGenModule::ConstructAttributeList(StringRef Name,
   // * call sites: both `nobuiltin` and "no-builtins" or "no-builtin-<name>".
   // * definitions: "no-builtins" or "no-builtin-<name>" only.
   // The attributes can come from:
   // * LangOpts: -ffreestanding, -fno-builtin, -fno-builtin-<name>
   // * FunctionDecl attributes: __attribute__((no_builtin(...)))
   addNoBuiltinAttributes(FuncAttrs, getLangOpts(), NBA);
 
   // Collect function IR attributes based on global settiings.
-  getDefaultFunctionAttributes(Name, HasOptnone, AttrOnCallSite, FuncAttrs);
+  getDefaultFunctionAttributes(Name, HasOptnone, HasOptsize, AttrOnCallSite,
+                               FuncAttrs);
 
   // Override some default IR attributes based on declaration-specific
   // information.
   if (TargetDecl) {
     if (TargetDecl->hasAttr<NoSpeculativeLoadHardeningAttr>())
       FuncAttrs.removeAttribute(llvm::Attribute::SpeculativeLoadHardening);
     if (TargetDecl->hasAttr<SpeculativeLoadHardeningAttr>())
       FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);

clang/lib/CodeGen/CodeGenModule.h

private:
   /// Check whether we can use a "simpler", more core exceptions personality
   /// function.
   void SimplifyPersonality();
 
   /// Helper function for ConstructAttributeList and
   /// addDefaultFunctionDefinitionAttributes.  Builds a set of function
   /// attributes to add to a function with the given properties.
   void getDefaultFunctionAttributes(StringRef Name, bool HasOptnone,
-                                    bool AttrOnCallSite,
+                                    bool HasOptsize, bool AttrOnCallSite,
                                     llvm::AttrBuilder &FuncAttrs);
 
   llvm::Metadata *CreateMetadataIdentifierImpl(QualType T, MetadataTypeMap &Map,
                                                StringRef Suffix);
 };
 
 }  // end namespace CodeGen
 }  // end namespace clang
 
 #endif // LLVM_CLANG_LIB_CODEGEN_CODEGENMODULE_H

clang/lib/CodeGen/CodeGenModule.cpp

void CodeGenModule::SetLLVMFunctionAttributesForDefinition(const Decl *D,
   // Track whether we need to add the optnone LLVM attribute,
   // starting with the default for this optimization level.
   bool ShouldAddOptNone =
       !CodeGenOpts.DisableO0ImplyOptNone && CodeGenOpts.OptimizationLevel == 0;
   // We can't add optnone in the following cases, it won't pass the verifier.
   ShouldAddOptNone &= !D->hasAttr<MinSizeAttr>();
   ShouldAddOptNone &= !D->hasAttr<AlwaysInlineAttr>();
 
+  bool HasOptimizeAttrO0 = false;
+  if (const auto *OA = D->getAttr<OptimizeAttr>())
+    HasOptimizeAttrO0 = OA->getOptLevel() == OptimizeAttr::O0;
+
   // Add optnone, but do so only if the function isn't always_inline.
-  if ((ShouldAddOptNone || D->hasAttr<OptimizeNoneAttr>()) &&
+  if ((ShouldAddOptNone || D->hasAttr<OptimizeNoneAttr>() ||
+       HasOptimizeAttrO0) &&
       !F->hasFnAttribute(llvm::Attribute::AlwaysInline)) {
     B.addAttribute(llvm::Attribute::OptimizeNone);
 
     // OptimizeNone implies noinline; we should not be inlining such functions.
     B.addAttribute(llvm::Attribute::NoInline);
 
     // We still need to handle naked functions even though optnone subsumes
     // much of their semantics.
     if (D->hasAttr<NakedAttr>())
       B.addAttribute(llvm::Attribute::Naked);
 
     // OptimizeNone wins over OptimizeForSize and MinSize.
     F->removeFnAttr(llvm::Attribute::OptimizeForSize);
     F->removeFnAttr(llvm::Attribute::MinSize);
   } else if (D->hasAttr<NakedAttr>()) {
     // Naked implies noinline: we should not be inlining such functions.
     B.addAttribute(llvm::Attribute::Naked);
     B.addAttribute(llvm::Attribute::NoInline);
   } else if (D->hasAttr<NoDuplicateAttr>()) {
     B.addAttribute(llvm::Attribute::NoDuplicate);
-  } else if (D->hasAttr<NoInlineAttr>() && !F->hasFnAttribute(llvm::Attribute::AlwaysInline)) {
+  } else if (D->hasAttr<NoInlineAttr>() &&
+             !F->hasFnAttribute(llvm::Attribute::AlwaysInline)) {
     // Add noinline if the function isn't always_inline.
     B.addAttribute(llvm::Attribute::NoInline);
   } else if (D->hasAttr<AlwaysInlineAttr>() &&
              !F->hasFnAttribute(llvm::Attribute::NoInline)) {
     // (noinline wins over always_inline, and we can't specify both in IR)
     B.addAttribute(llvm::Attribute::AlwaysInline);
   } else if (CodeGenOpts.getInlining() == CodeGenOptions::OnlyAlwaysInlining) {
     // If we're not inlining, then force everything that isn't always_inline to

clang/lib/Sema/SemaDeclAttr.cpp

if (MinSizeAttr *MinSize = S.mergeMinSizeAttr(D, AL))
     D->addAttr(MinSize);
 }
 
 static void handleOptimizeNoneAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   if (OptimizeNoneAttr *Optnone = S.mergeOptimizeNoneAttr(D, AL))
     D->addAttr(Optnone);
 }
 
+static void handleOptimizeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  StringRef Arg;
+  if (!S.checkStringLiteralArgumentAttr(AL, 0, Arg))
+    return;
+
+  StringRef Level;
+  // Check if argument is prefixed with "-O" or "O"
+  if (Arg.str().rfind("-O", 0) == 0)
+    Level = Arg.substr(2);
+  else if (Arg.str().rfind("O", 0) == 0)
+    Level = Arg.substr(1);
+  else
+    S.Diag(AL.getLoc(), diag::warn_invalid_optimize_attr_level) << Arg;
+
+  llvm::StringMap<OptimizeAttr::OptLevelKind> StrToKind = {
+      {"", OptimizeAttr::O0},  {"s", OptimizeAttr::Os},
+      {"g", OptimizeAttr::Og}, {"fast", OptimizeAttr::Ofast},
+      {"z", OptimizeAttr::Oz}, {"0", OptimizeAttr::O0},
+      {"1", OptimizeAttr::O1}, {"2", OptimizeAttr::O2},
+      {"3", OptimizeAttr::O3}, {"4", OptimizeAttr::O4},
+  };
+
+  auto It = StrToKind.find(Level.str());
+  if (It != StrToKind.end()) {
+    D->addAttr(::new (S.Context) OptimizeAttr(S.Context, AL, "", It->second));
+    return;
+  }
+
+  llvm::APInt Num;
+  if (!Level.getAsInteger(10, Num)) {
+    // Limit level to -O4 if higher.
+    std::string Level = std::to_string(Num.getLimitedValue(4));
+    D->addAttr(::new (S.Context)
+                   OptimizeAttr(S.Context, AL, "", StrToKind[Level]));
+    return;
+  }
+
+  S.Diag(AL.getLoc(), diag::warn_invalid_optimize_attr_level) << Arg;
+}
+
 static void handleConstantAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   const auto *VD = cast<VarDecl>(D);
   if (VD->hasLocalStorage()) {
     S.Diag(AL.getLoc(), diag::err_cuda_nonstatic_constdev);
     return;
   }
   // constexpr variable may already get an implicit constant attr, which should
   // be replaced by the explicit constant attr.
case ParsedAttr::AT_ExternalSourceSymbol:
     handleExternalSourceSymbolAttr(S, D, AL);
     break;
   case ParsedAttr::AT_MinSize:
     handleMinSizeAttr(S, D, AL);
     break;
   case ParsedAttr::AT_OptimizeNone:
     handleOptimizeNoneAttr(S, D, AL);
     break;
+  case ParsedAttr::AT_Optimize:
+    handleOptimizeAttr(S, D, AL);
+    break;
   case ParsedAttr::AT_EnumExtensibility:
     handleEnumExtensibilityAttr(S, D, AL);
     break;
   case ParsedAttr::AT_SYCLKernel:
     handleSYCLKernelAttr(S, D, AL);
     break;
   case ParsedAttr::AT_SYCLSpecialClass:
     handleSimpleAttribute<SYCLSpecialClassAttr>(S, D, AL);

clang/test/CodeGen/attr-optimize.c

+// RUN: %clang_cc1 -O2 -S -emit-llvm %s -o - | FileCheck %s --check-prefix=O2
+// RUN: %clang_cc1 -O0 -S -emit-llvm %s -o - | FileCheck %s --check-prefix=O0
+
+__attribute__((optimize("O0"))) void f1(void) {}
+// O2: @f1{{.*}}[[ATTR_OPTNONE:#[0-9]+]]
+// O0: @f1{{.*}}[[ATTR_OPTNONE:#[0-9]+]]
+
+__attribute__((optimize("Os"))) void f2(void) {}
+// O2: @f2{{.*}}[[ATTR_OPTSIZE:#[0-9]+]]
+// O0: @f2{{.*}}[[ATTR_OPTNONE]]
+
+__attribute__((optimize("Og"))) void f3(void) {}
+// O2: @f3{{.*}}[[ATTR_OPTSIZE]]
+// O0: @f3{{.*}}[[ATTR_OPTNONE]]
+
+__attribute__((optimize("Oz"))) void f4(void) {}
+// O2: @f4{{.*}}[[ATTR_OPTSIZE]]
+// O0: @f4{{.*}}[[ATTR_OPTNONE]]
+
+__attribute__((optimize("Ofast"))) void f5(void) {}
+// O2: @f5{{.*}}[[ATTR_OPTSIZE]]
+// O0: @f5{{.*}}[[ATTR_OPTNONE]]
+
+// O2: attributes [[ATTR_OPTNONE]] = { {{.*}}optnone{{.*}} }
+// O2: attributes [[ATTR_OPTSIZE]] = { {{.*}}optsize{{.*}} }
+
+// Check that O0 overrides the attribute
+// O0: attributes [[ATTR_OPTNONE]] = { {{.*}}optnone{{.*}} }

clang/test/Misc/pragma-attribute-supported-attributes-list.test

 // CHECK-NEXT: ObjCRequiresSuper (SubjectMatchRule_objc_method)
 // CHECK-NEXT: ObjCReturnsInnerPointer (SubjectMatchRule_objc_method, SubjectMatchRule_objc_property)
 // CHECK-NEXT: ObjCRootClass (SubjectMatchRule_objc_interface)
 // CHECK-NEXT: ObjCRuntimeName (SubjectMatchRule_objc_interface, SubjectMatchRule_objc_protocol)
 // CHECK-NEXT: ObjCRuntimeVisible (SubjectMatchRule_objc_interface)
 // CHECK-NEXT: ObjCSubclassingRestricted (SubjectMatchRule_objc_interface)
 // CHECK-NEXT: OpenCLIntelReqdSubGroupSize (SubjectMatchRule_function)
 // CHECK-NEXT: OpenCLNoSVM (SubjectMatchRule_variable)
+// CHECK-NEXT: Optimize (SubjectMatchRule_function)
 // CHECK-NEXT: OptimizeNone (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: Overloadable (SubjectMatchRule_function)
 // CHECK-NEXT: Owner (SubjectMatchRule_record_not_is_union)
 // CHECK-NEXT: ParamTypestate (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: PassObjectSize (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: PatchableFunctionEntry (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: Pointer (SubjectMatchRule_record_not_is_union)
 // CHECK-NEXT: RandomizeLayout (SubjectMatchRule_record)

clang/test/Sema/attr-optimize.c

+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+__attribute__((optimize(a))) // expected-error {{use of undeclared identifier 'a'}}
+void
+f1() {}
+
+int b = 1;
+__attribute__((optimize(b))) // expected-error {{'optimize' attribute requires a string}}
+void
+f2() {}
+
+__attribute__((optimize("O0", "O1"))) // expected-error {{'optimize' attribute takes one argument}}
+void
+f3() {}
+
+__attribute__((optimize("Og"))) // expected-no-error
+void
+f4() {}
+
+__attribute__((optimize("O-1"))) // expected-warning {{invalid optimization level 'O-1' specified; the argument to '-O' should be a non-negative integer, '-Os', '-Oz', '-Og', or '-Ofast'; attribute ignored}}
+void
+f5() {}
+
+__attribute__((optimize("O+1"))) // expected-warning {{invalid optimization level 'O+1' specified; the argument to '-O' should be a non-negative integer, '-Os', '-Oz', '-Og', or '-Ofast'; attribute ignored}}
+void
+f6() {}
+
+__attribute__((optimize("O0"))) // expected-no-error
+void
+f7() {}
+
+__attribute__((optimize("Os"))) // expected-no-error
+void
+f8() {}
+
+__attribute__((optimize("O44"))) // expected-no-error
+void
+f9() {}
+
+__attribute__((optimize("Oz"))) // expected-no-error
+void
+f10() {}
+
+__attribute__((optimize("Ofast"))) // expected-no-error
+void
+f11() {}
+
+__attribute__((optimize("O"))) // expected-no-error
+void
+f12() {}
+
+__attribute__((optimize("O0"))) // expected-error {{expected identifier or '('}}