similar to: [LLVMdev] Runtime optimization and other doubts

Hey Andy > One easy pattern to follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; //

Isnt all the command line options only relevant to the driver, so if all the command line options are migrated to the driver, the library will be free from static initializers. Doesnt this make it more cleaner ? Thanks Shankar Easwaran On 9/17/2013 12:10 PM, Andrew Trick wrote: > LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library

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

----- Original Message ----- > LLVM's internal command line library needs to evolve. We have an > immediate need to build LLVM as a library free of static > initializers, but before brute-force fixing this problem, I'd like > outline the incremental steps that will lead to a desirable long > term solution. We want infrastructure in place to provide an > evolutionary path.

Hi Andy, I definitely agree with the desire to remove command line options and having them be initialized as part of the pass would be general goodness. However, a few possible issues: a) a number of command line options aren't really connected to passes per-se (backend options) b) "As long as pass initialization happens before parseCommandLine, usage should be consistent." I'm

On Sep 17, 2013, at 11:25 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Isnt all the command line options only relevant to the driver, so if all the command line options are migrated to the driver, the library will be free from static initializers. > > Doesnt this make it more cleaner ? Yes, but less convenient for developing experimental passes. I think we want to

Wait, I have a terrible idea. Why don't we roll our own .init_array style appending section? I think we can make this work for all toolchains we support. We'd have something like: struct PODOptData { const char *FlagName; ... // Common POD stuff, can be initialized at ParseCommandLine time. }; LLVM_SECTION(".llvmopt") PODOptData OptionRegisterer = { "foo_flag",

>> I definitely agree with the desire to remove command line options and >> having them be initialized as part of the pass would be general >> goodness. However, a few possible issues: >> >> a) a number of command line options aren't really connected to passes >> per-se (backend options) > > We don’t have to ban the old-style options. They can live-on

On Sep 17, 2013, at 10:31 AM, Eric Christopher <echristo at gmail.com> wrote: > Hi Andy, > > I definitely agree with the desire to remove command line options and > having them be initialized as part of the pass would be general > goodness. However, a few possible issues: > > a) a number of command line options aren't really connected to passes > per-se

LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to provide an evolutionary path. In the near term, clients who need llvm-the-library with

----- Original Message ----- > From: "Simone Atzeni" <simone.at at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, cfe-dev at cs.uiuc.edu, openmp-dev at dcs-maillist2.engr.illinois.edu > Sent: Tuesday, October 21, 2014 3:52:38 PM > Subject: Re: [LLVMdev] [cfe-dev][Openmp-dev] Provide LLVM IR and OpenMP LLVM IR as input

On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote: > Wait, I have a terrible idea. Why don't we roll our own .init_array style > appending section? I think we can make this work for all toolchains we > support. > Andy and I talked about this, but I don't think its worth it. My opinion is: 1. For tool options (the top-level llc, opt, llvm-as

Revision: 34 Author: freyfogle Date: Mon Sep 21 00:21:06 2009 Log: removed deprecated method draggable, all controls off when first creating the map, bit of work on adding controls, though still doesnt seem to be working correctly http://code.google.com/p/mapstraction/source/detail?r=34 Modified: /trunk/source/mxn.googlev3.core.js ======================================= ---

Harold: As a general rule, if you are using eval(parse(...)) you are doing it poorly in R; cf library("fortunes") fortune(106) Why is something like this not suitable: fun1 <- function(a1,a2,a3 = c("hi","by")) { cat(a3,a1+a2,"\n") } > fun1 (1,2) hi by 3 > fun1(1,2, a3 = "whoopee") whoopee 3 ... or, if you want to include the

Revision: 30 Author: freyfogle Date: Sun Sep 20 06:26:44 2009 Log: jslint now passing for google and googlev3 http://code.google.com/p/mapstraction/source/detail?r=30 Modified: /trunk/build.xml /trunk/source/mxn.google.core.js /trunk/source/mxn.googlev3.core.js ======================================= --- /trunk/build.xml Sun Sep 20 06:13:41 2009 +++ /trunk/build.xml Sun Sep 20 06:26:44

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 function attributes in IR. You can just query the function attribute wherever without any need

I am writing a program where non-technical R users will read in a config file and the config file will then parse the arguments found within the config and pass them to respective functions. I'm having trouble (efficiently) writing a piece of code to retain quotation marks around the argument which requires it as input, as found in the example function below, myFuncton1. Below is a minimal,

Hello everybody, I''m working with Version 3 of Google Maps JavaScript API, and I have the next code: In a layout of my application: <script type="text/javascript" src="http://ajax.googleapis.com/ajax/ libs/jquery/1.4.1/jquery.min.js"></script> <script type="text/javascript" src="http://maps.google.com/maps/api/js?

> Is there something I could do A_ Instead of 6.03, try 6.04-pre1 (not pre2 and not pre3, but pre1). Please remember to change _all_ related files to the same version, not just lpxelinux.0. Alternatively (and in many cases, even better) you could try current Debian's "Unstable" packages, which are "more up-to-date" than 6.04-pre1. B_ In the configuration file,

> > Sounds like you may want to contact Cisco... > > And tell them what? There's a bug in their PXE/BIOS stack somewhere? Just some random and humble thoughts... Perhaps it would be worth some additional tests? Maybe a test with pxelinux.0 version 4.07? And using "LINUX", not "KERNEL": ### DEFAULT biginitrd PROMPT 0 LABEL biginitrd LINUX mykernel INITRD