search for: commandflags

Hi Folks, Commit ac1d23ed7de01fb3a18b340536842a419b504d86 introduces a change in the way CodeGen and MC CommandFlags are handled. It's a change that may impact some devs, so I'd better give a small notice here. Basically previous approach was to bundle all options in a .inc file that declares a bunch of llvm::cl options. This file was lying in include/llvm and was to be included in client code. To avoid...

Thank you all for your suggestions! @David, thanks for the advice, I'll check MCOptions again and look into LLVMContext. @Craig, @Aaron, great suggestion, moving the option away from CommandFlags.inc to a more appropriate file and adding an extern declaration to the corresponding header gives me more flexibility and allows me to invoke the option by using -mllvm. From my current understanding, adding a function attribute would not be sufficient, since I need to query the option unrelated to...

CommandFlags.inc is only included by llc and opt. I think it mostly just sets things on TargetMachine and TargetOptions and connects them to command line options. Clang has its own code for setting up TargetMachine and TargetOptions. I think a lot of configuration things these days tend to be done with functio...

While looking at adding a TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? - Stephen Crane -------------- next part ----...

While looking at adding a new TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? - Stephen Crane -------------- next part ---...

...ly modify certain mechanisms of the x86 backend, as well as certain functions within PrologEpilogInserter (so my changes are not confined to a single pass - e.g. they include changes to the x86RegisterInfo constructor). In my current solution, I have added an option within llvm/include/llvm/CodeGen/CommandFlags.inc to enable my modifications (the modifications are placed within if-conditions in multiple segments of the code). This requires me to compile test code in two steps (first run clang with -emit-llvm, then run llc with my option enabled in the command line). Now I would like to be able to enable...

...://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078785.html These are the changes I plan to make: 1. In llc.cpp (and any other tools that use the option), change the function attribute in the IR based on the value of command line option “enable-unsafe-pf-math” (EnableUnsafeFPMath, defined in CommandFlags.h). 2. Replace usages of TargetOptions::UnsafeFPMath with calls to a function which gets the value of attribute “unsafe-fp-math” in the IR. 3. Stringify function attribute “unsafe-fp-math” and append it to the string that is used as the lookup key in TargetMachine::getSubtargetImpl(const Function...

On 18 June 2016 at 02:58, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I haven't looked at the implementation, but conceptually this looks nice! Indeed, really nice! > We talked internally about an option to build something like a single "llvm" > binary that would be symlinked by opt/llc/etc. So that when you invoke > `opt`, it would run the

...mmand-line option's namespace opt::cl in CommandLine.cpp, which provides useful function for parsing options. However we also have OptTable in OptTable.h and we are confused why they have similar classes for options. Our implementation plan is to build a new OptTable for opt options defined in CommandFlags.h with their values and call its method when --autocomplete flag was passed to opt. We believe that this interface will also be useful to future development for opt command-line flags. Additionally, these are the type of flags which we already supported: * Clang flags * Clang flag values * CC1 fla...

....html > > > > These are the changes I plan to make: > > > > 1. In llc.cpp (and any other tools that use the option), change the > function attribute in the IR based on the value of command line > option “enable-unsafe-pf-math” (EnableUnsafeFPMath, defined in > CommandFlags.h). > > 2. Replace usages of TargetOptions::UnsafeFPMath with calls to a > function which gets the value of attribute “unsafe-fp-math” in the > IR. > > 3. Stringify function attribute “unsafe-fp-math” and append it to the > string that is used as the lookup key in > Target...

Hello, JIT compiler interferes with internal R completions: compiler::enableJIT(2) utils:::functionArgs("density", '') gives: utils:::functionArgs("density", '') Note: no visible global function definition for 'bw.nrd0' Note: no visible global function definition for 'bw.nrd' Note: no visible global function definition for 'bw.ucv'

On Thu, 2013-01-31 at 11:29 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > > ----- Original Message ----- > > > > > From: "Bill Schmidt" <wschmidt at

On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > ----- Original Message ----- > > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > > To: llvmdev at cs.uiuc.edu > > > > Sent:

...re is, see below. @Eric, "Does the patch do all of this?" Basically, yes, see http://reviews.llvm.org/D8506 The target-based default for the tuning parameter is done by code at the top of the DwarfDebug constructor; this really simplified supporting an option from the tool command lines (CommandFlags.h) and passing in a value from Clang. Given that the use of LLDB seems to be more aligned with OS than target architecture, trying to set up appropriate default tuning values somewhere under lib/Target just seemed too complicated. But if that's what you'd rather see, please comment in the...

I don’t think there was a driver patch so far, was there? -- adrian > On May 6, 2015, at 1:19 PM, Eric Christopher <echristo at gmail.com> wrote: > > Does the patch do all of this? > > -eric > > On Wed, May 6, 2015 at 1:18 PM Robinson, Paul <Paul_Robinson at playstation.sony.com <mailto:Paul_Robinson at playstation.sony.com>> wrote: > I just skimmed

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

> On Aug 19, 2014, at 1:32 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >>> * Nobs for which there is not a single right answer for all users. >>> There are very few of these currently and we expect it to remain like >>> that. These should not use cl::opt or static storage at all. They >>> should be an option passed to the

...below. > @Eric, "Does the patch do all of this?" Basically, yes, see > http://reviews.llvm.org/D8506 The target-based default for the tuning parameter is done by code at the top of the DwarfDebug constructor; this really simplified supporting an option from the tool command lines (CommandFlags.h) and passing in a value from Clang. Given that the use of LLDB seems to be more aligned with OS than target architecture, trying to set up appropriate default tuning values somewhere under lib/Target just seemed too complicated. But if that's what you'd rather see, please comment in the...