search for: optionregistri

Today command line arguments in LLVM are global variables. An example argument from Scalarizer.cpp is: static cl::opt<bool> ScalarizeLoadStore ("scalarize-load-store", cl::Hidden, cl::init(false), cl::desc("Allow the scalarizer pass to scalarize loads and store")); This poses a problem for clients of LLVM that aren’t traditional compilers (i.e. WebKit, and Mesa).

> On Aug 18, 2014, at 2:42 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > On 18 August 2014 14:49, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> Today command line arguments in LLVM are global variables. An example >> argument from Scalarizer.cpp is: >> >> static cl::opt<bool> ScalarizeLoadStore

I’d like to propose moving forward with the first phase of my proposal to make the cl::opt structures owned and eliminate global option storage. I’d also like to add to it that when updating passes I will ensure that each pass that has cl::opts also has a default constructor, an overridden constructor to populate each option, and the corresponding factory methods for the C API. Does this sound

> On Aug 18, 2014, at 3:09 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> Some passes take options directly in the constructor. For example >> >> Inliner::Inliner(char &ID, int Threshold, bool InsertLifetime) >> >> Maybe we could just say that there are two different types of options. >> The ones we want to expose to users

> 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

> On Aug 18, 2014, at 4:25 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > >> On Aug 18, 2014, at 3:21 PM, Chris Bieneman <beanz at apple.com> wrote: >> >> >>>> On Aug 18, 2014, at 3:09 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> >>>> Some passes take options directly in the

There are parts of this proposal that I really like, and there are others that I think are actually at opposition to the work we’re trying to do with cl::opt. > On Nov 14, 2014, at 2:44 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > +chrisb > >> On 2014-Nov-13, at 16:33, Akira Hatanaka <ahatanak at gmail.com> wrote: >> >> I'm

Hi all, Running LLVM 3.4 to create a custom pass for OpenCL transformations. I am attempting to GEP into a struct using IRBuilder's CreateStructGEP, but I keep getting this assert: aoc: ../../../../../../compiler/llvm/include/llvm/Instructions.h:703: llvm::Type* llvm::checkGEPType(llvm::Type*): Assertion `Ty && "Invalid GetElementPtrInst indices for type!"' failed.

cB->getType()->getPointerElementType()->dump(); gives: %struct.RB = type opaque2189 x_idx = builder.CreateStructGEP(cB, 0); cB->dump() gives: %struct.RB addrspace(1)* %cB $1 = void //To undo confusion, the last cB is the function arg name. For this example I unfortunately chose the same name for my argument Value* as the argument name. //Also one correction. I am running

If I do M.dump(), at the top of the output I have: %struct.RB = type opaque Further down I have: @.str18 = internal addrspace(2) constant [13 x i8] c"RB_t*\00" However nowhere does it dump the full struct type when I call "M.dump()". I have it explicitly defined above the kernel in the kernel file, but LLVM doesn't seem to pick it up. Opaque is a placeholder until it

> On Aug 19, 2014, at 11:09 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > On 19 August 2014 13:47, Chris Bieneman <beanz at apple.com> wrote: >> I’d like to propose moving forward with the first phase of my proposal to >> make the cl::opt structures owned and eliminate global option storage. > > For now, please eliminate only the static

Sure, it is the Rodinia 2.4 Hotspot benchmark OpenCL kernel (not my kernel), with the addition of my struct as the last argument in the kernel function. //------- kernel file start ------------------------------- #define BLOCK_SIZE 16 //dlowell's type #define BUFFER_LEN 0x100000 typedef struct RB{ unsigned int x; unsigned int y; int z[BUFFER_LEN]; unsigned int xx[BUFFER_LEN];

I'm working on fixing PR21471, which is about embedding codegen command line options into the bitcode as function or module-level attributes so that they don't get ignored when doing LTO. http://llvm.org/bugs/show_bug.cgi?id=21471 I have an initial patch (attached to this email) which enables clang/llvm to recognize one command line option, write it to the IR, and read it out in a