<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 19, 2014, at 7:00 PM, Jim Grosbach <<a href="mailto:grosbach@apple.com" class="">grosbach@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 19, 2014, at 6:51 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 19, 2014 at 8:44 PM, Bob Wilson<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:bob.wilson@apple.com" target="_blank" class="">bob.wilson@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Nov 19, 2014, at 6:06 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">So I am deeply concerned about the direction this is taking. I'm trying to catch up on the thread, but I think Chris already highlighted my issue:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 14, 2014 at 4:57 PM, Chris Bieneman<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:cbieneman@apple.com" target="_blank" class="">cbieneman@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class=""><span class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">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?</blockquote></div></blockquote><div class=""><br class=""></div></span><div class="">In discussions about the new cl::opt API I believe the general idea was that most of the options expressed using cl::opt are actually only relevant as debug options, so I think one big part of this work is really going to be identifying a subset of the current options which are actually relevant to expose in the IR.</div></div></blockquote><div class=""><br class=""></div><div class="">I think this is critical.</div><div class=""><br class=""></div><div class="">The whole idea of cl::opt API is for *debugging* options. IE, not supported, expected variations on how passes behave. Those should always be controlled (at the LLVM API layer) through constructors and parameters, not through a side-layer.</div><div class=""><br class=""></div><div class="">There are parts of LLVM currently abusing the cl::opt mechanism to control fundamental functionality, but we should *absolutely* not bake any part of that or support for that into the IR! We should go find and fix those places to use reasonable APIs. Once we have that, I am very supportive of getting a good system for transmitting these options in bitcode and such in order to better support LTO. However, I think that in essentially every case there are going to be two options:</div><div class=""><br class=""></div><div class="">1) Turn these options into function attributes because they can reasonably live as function attributes and different variations can co-exist within a module.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span>I have heard several people express strong opinions that even when those options are represented as function attributes, we will want a mechanism to override those with llc command line options for experimentation and debugging. If so, they will still need to exist as cl::opt (or some other equivalent). Are you suggesting otherwise?</div></div></blockquote><div class=""><br class=""></div><div class="">Yes and no.</div><div class=""><br class=""></div><div class="">You might have a debug override option using cl::opt (or whatever we replace it with).</div><div class=""><br class=""></div><div class="">Or you might have an LLC option (which might be implemented with cl::opt but is categorically different from the debugging options in common LLVM libraries) that explicitly constructs passes with options, and the passes might skip the function attribute when given a specific override.</div><div class=""><br class=""></div><div class="">Probably lots of other alternative ways of achieving this goal I haven't thought of really....</div><div class=""><br class=""></div><div class="">My point is that regardless of what technique you use to override options, the things that can be serialized through the IR should *not* include debugging only 'cl::opt' options in the common LLVM libraries.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I think I agree (I’m one of those “several people” Bob mentioned) with this. Depends on which options you consider debugging only and what that implies for when/how they interact with the rest of the stuff. Maybe a specific example or two on each side of the divide to help make sure we’re all defining terms in a somewhat compatible way?</div></div></div></div></blockquote><div><br class=""></div>Yes, I think a specific example would help.</div><div><br class=""></div><div>I keep saying this, but repetition might help: this is one piece of a much bigger problem and this proposal is NOT about moving all the cl::opt options into the IR. That would be insane. (Akira showed a bunch of them as an example because Eric asked what they would look like, but that wasn’t meant to imply that all those options would necessarily be put into the IR.) We need to look carefully at each option to decide whether it should be serialized in the IR.</div><div><br class=""></div><div>This proposal is about the mechanism that we use to do that for one subset of the relevant options.</div><div><br class=""></div><div>Let’s make it more specific and only consider the “-arm-long-calls” option. (I’m picking that arbitrarily as a simple example of something that seems like a good fit for a function attribute.) My assertion is that there are a number of other options that need to be handled in a similar way. We should figure out how to handle that kind of option and then we can talk later about which specific options fall into the category. If it turns out that “-arm-long-calls” is controversial or a bad example, we can pick a different one to discuss.</div><div><br class=""></div><div>* The clang driver translates the “-mlong-calls” option into “-backend-option -arm-long-calls”. Nothing in clang outside the driver knows anything about “-arm-long-calls". We need a way for clang to recognize “-arm-long-calls” and translate it to a function attribute. As Eric suggested (and as I had originally assumed we would do), one option would be to teach clang to recognize that as a cc1 option and then to translate it to a function attribute. That is certainly a possibility, but there are quite of lot of target-specific options like this, and I’m not convinced there is much to be gained by baking them all into clang.</div><div><br class=""></div><div>* There are a bunch of tests in llvm that pass “-arm-long-calls” as a command line option to llc. We could rewrite all those tests to add the function attribute instead, but it is useful to have the llc option available for debugging and experiments, and it would be nice to avoid the test churn to rewrite them all.</div><div><br class=""></div><div>* There are a few places in ARMFastISel.cpp and ARMISelLowering.cpp that check the EnableARMLongCalls option. These should be changed to check for the function attribute once it is available. It would be good to avoid having to check BOTH the option and the attribute. One way to do that is to have the the llc option cause the corresponding attribute to be added to all the functions. Then the backend can just check for the attribute.</div><div><br class=""></div><div>* The same backend option parsing is shared between llc and clang. When they see the “-arm-long-calls” option, they both need to do the same thing. If the option is one that gets serialized into the IR as a function attribute, both llc and clang need to go through all the functions and add the attribute to each of them. This is exactly what Akira’s patch supports. For the backend options that we choose to mark with codegenoption::FunctionAttrCategory, it will translate them to function attributes.</div><div><br class=""></div><div>Akira and I talked about this with Chris B. and Pete Cooper, and I think we reached agreement that this is mostly orthogonal to Chris’s work. Chris wants to have an OptionRegistry and an OptionStore. If we had those things, we would still need a way to translate “-arm-long-calls” into a function attribute.</div><div><br class=""></div><div>The best alternative proposal I can see is to have clang understand all these backend options and have code to map each one to a function attribute. But, that doesn’t do anything to support keeping the llc option. Personally I think it would be a very nice design to just completely drop all those llc options (at least for the set of options that we choose to serialize as function attributes) and rely on the function attributes as the only way to specify those things. Jim and Evan seemed to think I was crazy for even suggesting that…. and I suspect they’re probably right.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""><div class=""><br class=""></div><div class="">2) Keep the options as module-level options, but insist that they match for all modules being merged in LTO.</div></span></div></blockquote></div></div></blockquote></div></div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div>Yes, we will need to do this for some set of options, hopefully not too many. That’s outside the scope of this proposal, though. We can probably use a similar approach for module-level options, but let’s take it one step at a time.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><span class=""><div class=""><br class=""></div><div class="">3) (very rare) have clean, well specified merge semantics to merge different options from different modules in LTO. I think these only come up quite rarely. The only really good example I know of would be something like "library link dependencies" where it is a list that we clearly just take the union to merge.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">3. Where should the command line options or module/function attributes be stored once they are read out from the IR?<br class=""></blockquote></div></blockquote><div class=""><br class=""></div>My suggestion would be the OptionStore that I proposed here: <a href="http://reviews.llvm.org/D6207" target="_blank" class="">http://reviews.llvm.org/D6207</a><div class=""></div><br class="">Not to knock the option store (i quite like it), but I think that should be reserved for the cl::opt-style (but with your new API which is way better) debugging options, and never touch the IR.</span><span class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></span></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" class="">http://llvm.cs.uiuc.edu</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>