<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 14, 2014 at 1:58 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Akira,<br><br><div>This is very closely related to the work I've been doing and so I care quite a bit about it. I've implemented some of this - at least as far as the global TargetMachine options in the current work for Subtarget code generation - which is what some of this comes down to. I'll respond inline here:</div><br><div class="gmail_quote"><span>On Thu Nov 13 2014 at 4:35:08 PM Akira Hatanaka <<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'm working on fixing PR21471, which is about embedding codegen command line options into the bitcode as function or module-level attributes so that they don't get ignored when doing LTO.</div><div><br></div><div><a href="http://llvm.org/bugs/show_bug.cgi?id=21471" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=21471</a></div><div><br></div><div>I have an initial patch (attached to this email) which enables clang/llvm to recognize one command line option, write it to the IR, and read it out in a backend pass. I'm looking to get feedback from the community on whether I'm headed in the right direction or whether there are alternate ideas before I go all the way on fixing the PR.</div></div></blockquote><div><br></div></span><div>Glad to see you working on it.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> Specifically, I'd like to know the answers to the following questions:</div><div><br></div><div>1. How do we make sure we continue to be able to use the command line options we've been using for llc and other tools?</div><div>2. How to handle cases where two functions in a module have different sets of command line options?</div><div>3. Where should the command line options or module/function attributes be stored once they are read out from the IR?</div><div><br></div></div></blockquote><div><br></div></span><div>Yes. These are some of the important questions. I think you're missing a few things to take into consideration:</div><div><br></div><div>a) How does this change the pass manager? Some of the command line options (many) change which passes are run when. It should be as simple as checking the function attribute for each pass to decide when to run, but if one invokes a chain then you might have other issues or if the command line option invokes module/cgscc passes (see c below).</div><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>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.</div><div><br></div></div></blockquote><div><br></div><div>Yes, I saw that code. I was thinking I would have to change the map's key type to a tuple of strings and options, but perhaps there is a more efficient way to do the look up.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div>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. 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).</div><div><br></div></div></blockquote><div><br></div><div>Is there a way to attach a subtarget feature string to a function without using AttributeSet? I'm not sure I understand why subtarget features are preferable to function attributes.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div>d) linkonce_odr functions with different attributes</div><div><br></div><div>e) How to organize these so that it's easy for a particular target to know what attributes it might put on a function or module?</div><div><br></div><div>Probably more :)</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Other possible ideas that I've discussed or thought about, but haven't implemented:</div><div><br></div><div>1. Treat cl::opt options as overrides, possibly by setting a bit that indicates the option has been specified in the command line.</div><div><br></div><div>2. Extend the idea proposed in the discussion on llvm-dev about removing static initializer for command line options:</div><div><br></div><div><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html</a></div><div><br></div><div>I looked at the code that was checked in to trunk and it seems to me that it isn't possible to have storage for command line options on a per-function storage basis yet, which I think is necessary if the functions in a module have different sets of command line options.</div></div><br></blockquote><div><br></div></span><div>I don't think either of these are a good idea.</div><div><br></div><div>Thoughts?</div><span><font color="#888888"><div><br></div><div>-eric</div></font></span></div>
</blockquote></div><br></div></div>