<div dir="ltr">Are llc command line options all that critical? It's not that hard to edit the attributes directly or remove them with sed.<div><br></div><div>The less codegen depends on llc command line flags, the better, IMO.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 11:34 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As we encode more CodeGen and target-specific options in bitcode to<br>
support LTO, we risk crippling `llc` as a debugging tool.  In<br>
particular, `llc` command-line options are generally ignored when a<br>
function has an attribute set explicitly, but the plan of record is for<br>
`clang` to explicitly encode all (or most) CodeGen options -- even the<br>
target defaults.<br>
<br>
Changing `clang` to store target defaults on the module will allow us to<br>
continue to override them when running `llc`.  The right precedence<br>
would be:<br>
<br>
  1. Explicit attributes set on the function.<br>
  2. `llc` command-line options.<br>
  3. Default function attributes stored on the module.<br>
<br>
(Outside of `llc`, skip step 2.)<br>
<br>
In `lib/Linker` (i.e., `llvm-lto`, `llvm-link`, `libLTO.dylib`),<br>
defaults should be pushed down as explicit function attributes.<br>
<br>
Default function-level attributes<br>
=================================<br>
<br>
I've attached patches with a reference implementation.<br>
<br>
  - 0001: Canonicalize access to function attributes to use<br>
    `getFnAttribute()` and `hasFnAttribute()`.  (This seems like a nice<br>
    cleanup regardless?)<br>
  - 0002: Add the feature.<br>
  - 0003: Use it in `clang` for function attributes based solely on<br>
    `CodeGenOptions`.<br>
<br>
They look like this in assembly:<br>
<br>
    attributes default = { "no-frame-pointer-elim"="false" }<br>
<br>
Limitations<br>
===========<br>
<br>
There are a few limitations with this approach (at least, with my<br>
reference implementation).<br>
<br>
  - `Function::getAttributes()` only reflects the explicitly specified<br>
    attributes, skipping those set as module defaults.<br>
  - If an enum attribute is set as a default, there's no way for a<br>
    function-attribute to override it.  In practice, we could avoid the<br>
    feature for enum attributes.<br>
  - `CallSite` instructions store function-level attributes, but don't<br>
    forward to the module-level defaults.  There are places (like the<br>
    calls to `EmitUnaryFloatFnCall()` in `-simplify-libcalls`) where we<br>
    use the callee function attributes to set the call site attributes.<br>
    In practice, we could avoid the feature for attributes that are<br>
    meaningful for call sites.<br>
  - Intrinsics' attributes are independent of `CodeGenOptions`, and set<br>
    via `Instrinsic::getAttributes()`.  With this change they'd inherit<br>
    the default attributes like other functions.  Is this a problem?<br>
    If so, we can add a flag on `Function` that inhibits forwarding to<br>
    the defaults.<br>
<br>
Thoughts?  Other ideas for solving the `llc` problem?<br>
<br>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>