search for: createxxx

...construct... a type mismatch in the values fed to CreateCall, for instance, wouldn't corrupt memory; the error could be reported and the CallInst discarded. On the other hand, of course, if the client is expected to check for that stuff, it would slow things down to check for it again on each CreateXXX call, so I certainly see the logic in keeping that the way it is. I think it would be a big improvement for the asserts in those cases to print out what values it expected and what values it got, say by dumping the offending Value or Type objects to the console along with the line in Instructions....

...und it easy to use the IRBuilder to create instructions without inserting them into a BB, storing them somewhere (vector, map ... etc) and later on inserting all of them in one go into their positions in the BBs. What I do is similar to this: IRBuilder<> IB(Context); Vector.push_back(IB.CreateXXX()); Vector.push_back(IB.CreateXXX()); Vector.push_back(IB.CreateXXX()); ... // Other stuff for (SmallVectorImpl<Instruction*>::iterator I = Vector.begin(), E = Vector.end(); I != E; ++I) { SomeBB->getInstList().insert(SomeInstruction, *I); } If I add the instructions like this I ge...

On Aug 19, 2009, at 7:29 PM, Óscar Fuentes wrote: Eli Friedman <eli.friedman at gmail.com> writes: > Besides, in my experience all LLVM asserts I see are Type mismatches > for > instructions and similar cases, i.e., errors about my compiler > producing > wrong LLVM "code" through the API, plus some occasional bug on LLVM, > sometimes about one layer passing

Is there some kind of guide to the various optimization passes? I see their names in the class list, and the various "createXXX" functions, but I'm not sure if there are ordering requirements or perhaps unsafe optimizations. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail. -...

...8, 2018 at 9:03 PM, mayuyu.io <admin at mayuyu.io> wrote: > Hmmmm that’s strange. Do you get an assert when you build LLVM with this > code in Debug Mode or is it simply null pointer dereference? > On a side note, usually when doing transforms similar to yours I use > IRBuilder’s CreateXXX followed by a ReplaceInstWithInst which works > perfectly fine for me. > > Zhang > > 在 2018年8月9日，00:29，Ahmad Nouralizadeh <ahmadnouralizadeh at gmail.com> 写道： > > Hi. Thanks. I changed the code but the problem exists. This is my new code > which is again very simple: &...

Hi. Thanks. I changed the code but the problem exists. This is my new code which is again very simple: ... bool runOnFunction(Function &F) override { vector<Instruction *> dels; dels.clear(); for (inst_iterator It = inst_begin(&F), Ie = inst_end(&F); It != Ie;) { Instruction *I = &*(It++); if (auto* op = dyn_cast<BinaryOperator>(I)) { IRBuilder<NoFolder>

Hi, On 06/01/13 16:48, edA-qa mort-ora-y wrote: > Is there some kind of guide to the various optimization passes? I see > their names in the class list, and the various "createXXX" functions, > but I'm not sure if there are ordering requirements or perhaps unsafe > optimizations. there are no ordering requirements, in the sense that all passes are supposed to work correctly regardless of the order they are run in. Note that "work correctly" doesn...

Hi Talin, > I find that I call the static methods in ConstantExpr a *lot* without going > through IRBuilder - hundreds of times in my frontend. My language generates a > lot of static data - reflection information, trace tables for the garbage > collector, dispatch tables, runtime annotations, static object instances, and so > on. (In fact there's a special helper class

...cale very well, as I'd have to manually > enumerate all .objs that are transforms and insert this list into > every project that builds an executable that needs them. I only have the problem with the X86TargetMachine because in the case of the optimization passes I explicitly call the createXXXPass functions. 'opt' creates passes by name instead and that's why it gets into trouble. > So there's only two ways of dealing with this. The first is to use > DLLs. To prevent code from being duplicated in multiple DLLs and the > EXE, the bulk of the code in lib/ wil...

Jeff Cohen wrote: > OK, there may be some light at the end of the tunnel. I *can* force > an arbitrary .obj file to become part of the executable, one that is > not part of the executable's project. This is sufficient to eliminate > the global variable hack Morten introduced for the X86 target. > > But this still doesn't scale very well, as I'd have to manually

...into it. It would be useful to allow users of LLVM to control how (and more importantly where) memory is allocated by LLVM. This is another pretty large, sweeping change that will affect every "new" in LLVM. The various Class::get() methods would need to be altered as well as the various createXXX functions. To minimize the impact, we would subclass every root class in the LLVM inheritance hierarchy from some "Allocatee" class that implements operators new and delete. This base class would handle dispatching operator new to a user-installed version, if provided. Otherwise it just d...