Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Duncan P. N. Exon Smith <dexonsmith <at> apple.com>
Subject: [RFC] Storing default function attributes on the module
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Thursday 12th February 2015 07:34:58 UTC (over 3 years ago)
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?
 
CD: 5ms