<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Yes. These are some of the important questions. I think you're missing a few things to take into consideration:<br>
><br>
> a) How does this change the pass manager? Some of the command line options (many) change which passes are run when.<br>
<br>
Unfortunately the pass manager isn't a safe place to hack right now.<br>
<br></blockquote><div><br></div><div>*shrug* Just hack it if necessary.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It should be as simple as checking the function attribute for each pass to decide when to run,<br>
<br>
Right, these are easy.<br></blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> but if one invokes a chain then you might have other issues<br>
<br>
Just for clarity, if an option changes the passes from:<br>
<br>
    -instcombine<br>
<br>
to:<br>
<br>
    -instcombine -some-pass1 -some-pass2 -instcombine<br>
<br>
then ideally, we'd attach an attribute to the functions affected by<br>
that option, and `-some-pass1 -some-pass2 -instcombine` would be<br>
skipped for functions without that attribute.<br>
<br>
IIUC, you're saying that skipping the second -instcombine is hard,<br>
which I agree with.<br>
<br>
Agreed.  I'm comfortable leaving that to be solved later, once the<br>
new pass manager is in place.  Thoughts?<br></blockquote><div><br></div><div>Agreed, I don't know of many of these anyhow outside of the atomic lowering.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> or if the command line option invokes module/cgscc passes (see c below).<br>
><br>
> b) Right now I'm using a combination of stringified target-cpu and target-features with each target's cpu specific attributes (i.e. something like mips16) being a separate option that gets plugged into the subtarget - if it controls the creation of a subtarget. I don't know that any do (at least a quick glance didn't seem to say), but if a command line option controls any of the initialization in the subtarget dependent features it'll need to be part of the key to look up the subtarget. If it doesn't then you'll just need to check the attribute, as you said, in the pass/lowering/thingy.<br>
><br>
> c) Which command line options need to be part of this interface? I don't necessarily think all of them should which could turn some of these into subtarget features that can just be added on to the functions as they go.<br>
<br>
Can you give an example of these?<br></blockquote><div><br></div><div>-mips16 is the trivial example that already exists. -mabi= would probably be another when you can change it per function. (__attribute__((pcs("aapcs")))). Probably more, just those are the ones that come to mind.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> If anything can't change between translation units then a module level flag that errors on merge would be applicable. I'd prefer not to use module level flags for things that can just be put on every function. The module level flags could be read into a subtarget specific global target options flag (ala soft-float).<br>
<br>
Agreed.<br>
<br>
> d) linkonce_odr functions with different attributes<br>
<br>
Doesn't this just get handled by lib/Linker?  I figure we keep the<br>
attributes of the version of the function that "wins".<br>
<br></blockquote><div><br></div><div>Right. Which one wins? You'll get inconsistent results depending on ordering. Of course, you'd get that without linking them, but we should do some sort of checking ideally.</div><div> </div><div>Not necessarily objecting to Akira's plan at the moment in case that was a concern.</div><div><br></div><div>-eric</div></div>