[LLVMdev] [RFC] Storing default function attributes on the module

[Sean Silva]

On Wed, Feb 11, 2015 at 11:34 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

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

Random comment, but this patch changes the IR without any updates to
LangRef (or its sub-pages).

-- Sean Silva


>   - 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?
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150218/a9b029d6/attachment.html>