<div dir="ltr">Hi Duncan,<div><br></div><div>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 :)<br><div class="gmail_quote"></div></div><div><br></div><div dir="ltr"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I think there are a few options/backend communications that aren't/haven't gone this way yet that are probably worth considering:</div><div><br></div><div>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.</div><div><br></div><div>Random backend flags: Anything for debugging.</div><div><br></div><div>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.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">They look like this in assembly:<br>
<br>
attributes default = { "no-frame-pointer-elim"="<u></u>false<u></u>" }<br>
<br></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>Ick. Pretty severe limitation? I.e. how would it work to test general attributes on a function during code gen?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- 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></blockquote><div><br></div><div>Hrm. This seems like a pretty severe limitation? Anything come to mind in practice.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- `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></blockquote><div><br></div><div>Sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Intrinsics' attributes are independent of `CodeGenOptions`, and set<br>
via `Instrinsic::getAttributes()`.<u></u> 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></blockquote><div><br></div><div>Seems reasonable.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thoughts? Other ideas for solving the `llc` problem?<br>
<br></blockquote><div><br></div><div>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 :)</div><div><span style="font-size:13.1999998092651px"><br></span></div><div><span style="font-size:13.1999998092651px">-eric </span></div></div></div></div>