Bob Wilson
2014-Nov-20 02:44 UTC
[LLVMdev] [RFC] Embedding command line options in bitcode (PR21471)
> On Nov 19, 2014, at 6:06 PM, Chandler Carruth <chandlerc at google.com> wrote: > > 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: > > On Fri, Nov 14, 2014 at 4:57 PM, Chris Bieneman <cbieneman at apple.com <mailto:cbieneman at apple.com>> wrote: >>> 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? > > 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. > > I think this is critical. > > 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. > > 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: > > 1) Turn these options into function attributes because they can reasonably live as function attributes and different variations can co-exist within a module.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?> > 2) Keep the options as module-level options, but insist that they match for all modules being merged in LTO. > > 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. > > >>> 3. Where should the command line options or module/function attributes be stored once they are read out from the IR? > > My suggestion would be the OptionStore that I proposed here: http://reviews.llvm.org/D6207 <http://reviews.llvm.org/D6207> > > 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. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141119/a30982ad/attachment.html>
Chandler Carruth
2014-Nov-20 02:51 UTC
[LLVMdev] [RFC] Embedding command line options in bitcode (PR21471)
On Wed, Nov 19, 2014 at 8:44 PM, Bob Wilson <bob.wilson at apple.com> wrote:> > On Nov 19, 2014, at 6:06 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > 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: > > On Fri, Nov 14, 2014 at 4:57 PM, Chris Bieneman <cbieneman at apple.com> > wrote: > >> 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? >> >> >> 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. >> > > I think this is critical. > > 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. > > 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: > > 1) Turn these options into function attributes because they can reasonably > live as function attributes and different variations can co-exist within a > module. > > > 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? >Yes and no. You might have a debug override option using cl::opt (or whatever we replace it with). 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. Probably lots of other alternative ways of achieving this goal I haven't thought of really.... 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.> > > 2) Keep the options as module-level options, but insist that they match > for all modules being merged in LTO. > > 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. > > >> 3. Where should the command line options or module/function attributes be >> stored once they are read out from the IR? >> >> >> My suggestion would be the OptionStore that I proposed here: >> http://reviews.llvm.org/D6207 >> > > 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. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141119/5b772037/attachment.html>
Jim Grosbach
2014-Nov-20 03:00 UTC
[LLVMdev] [RFC] Embedding command line options in bitcode (PR21471)
> On Nov 19, 2014, at 6:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Nov 19, 2014 at 8:44 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: > >> On Nov 19, 2014, at 6:06 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: >> >> 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: >> >> On Fri, Nov 14, 2014 at 4:57 PM, Chris Bieneman <cbieneman at apple.com <mailto:cbieneman at apple.com>> wrote: >>>> 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? >> >> 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. >> >> I think this is critical. >> >> 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. >> >> 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: >> >> 1) Turn these options into function attributes because they can reasonably live as function attributes and different variations can co-exist within a module. > > 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? > > Yes and no. > > You might have a debug override option using cl::opt (or whatever we replace it with). > > 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. > > Probably lots of other alternative ways of achieving this goal I haven't thought of really.... > > 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.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?> > >> >> 2) Keep the options as module-level options, but insist that they match for all modules being merged in LTO. >> >> 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. >> >> >>>> 3. Where should the command line options or module/function attributes be stored once they are read out from the IR? >> >> My suggestion would be the OptionStore that I proposed here: http://reviews.llvm.org/D6207 <http://reviews.llvm.org/D6207> >> 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._______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141119/31c66396/attachment.html>