<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 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><br class=""></div><div>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><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><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=""></body></html>