As we encode more CodeGen and target-specific options in bitcode to
support LTO, we risk crippling `llc` as a debugging tool. In
particular, `llc` command-line options are generally ignored when a
function has an attribute set explicitly, but the plan of record is for
`clang` to explicitly encode all (or most) CodeGen options -- even the
target defaults.
Changing `clang` to store target defaults on the module will allow us to
continue to override them when running `llc`. The right precedence
would be:
1. Explicit attributes set on the function.
2. `llc` command-line options.
3. Default function attributes stored on the module.
(Outside of `llc`, skip step 2.)
In `lib/Linker` (i.e., `llvm-lto`, `llvm-link`, `libLTO.dylib`),
defaults should be pushed down as explicit function attributes.
Default function-level attributes
=================================
I've attached patches with a reference implementation.
- 0001: Canonicalize access to function attributes to use
`getFnAttribute()` and `hasFnAttribute()`. (This seems like a nice
cleanup regardless?)
- 0002: Add the feature.
- 0003: Use it in `clang` for function attributes based solely on
`CodeGenOptions`.
They look like this in assembly:
attributes default = { "no-frame-pointer-elim"="false" }
Limitations
===========
There are a few limitations with this approach (at least, with my
reference implementation).
- `Function::getAttributes()` only reflects the explicitly specified
attributes, skipping those set as module defaults.
- If an enum attribute is set as a default, there's no way for a
function-attribute to override it. In practice, we could avoid the
feature for enum attributes.
- `CallSite` instructions store function-level attributes, but don't
forward to the module-level defaults. There are places (like the
calls to `EmitUnaryFloatFnCall()` in `-simplify-libcalls`) where we
use the callee function attributes to set the call site attributes.
In practice, we could avoid the feature for attributes that are
meaningful for call sites.
- Intrinsics' attributes are independent of `CodeGenOptions`, and set
via `Instrinsic::getAttributes()`. With this change they'd inherit
the default attributes like other functions. Is this a problem?
If so, we can add a flag on `Function` that inhibits forwarding to
the defaults.
Thoughts? Other ideas for solving the `llc` problem?