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

[Eric Christopher]

Hi Duncan,

Been thinking about this a bit and a few comments/questions. I may have
misunderstood some things in your mail though so please feel free to
explain at me :)


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

I think there are a few options/backend communications that aren't/haven't
gone this way yet that are probably worth considering:

MCTargetOptions/TargetOptions: Basically a grab bag of functionality, some
of which is duplicated via attributes and some that's not. I think at least
some of these should be replaced by module flags, e.g. ABI.

Random backend flags: Anything for debugging.

I'm thinking things that are either set as Init(true/false) and affect
things at a global level and not just the function level.


> They look like this in assembly:
>
>     attributes default = { "no-frame-pointer-elim"="false" }
>
>
So, how do you see module merging and defaults working? (Yes, there were
testcases, but let's go with prose here. I found the testcases a bit hard
to reason.)


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

Ick. Pretty severe limitation? I.e. how would it work to test general
attributes on a function during code gen?


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

Hrm. This seems like a pretty severe limitation? Anything come to mind in
practice.


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

Sure.


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


> Thoughts?  Other ideas for solving the `llc` problem?
>
>
I think this is a good start, I think I'd like to worry about some of the
other issues in advance before we start incrementally changing things
though. (Also, I really have no other ideas :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/8a94e6d3/attachment.html>