similar to: InstCombine doesn't delete instructions with token

Yes, it's still respected in this case, as the only instructions that will be deleted have been RAUW with undef. Originally, all instructions where RAUW but only non-EHPad were deleted (that means EHPad were RAUW but not deleted). Then it was later patched by not RAUW token instructions and now not deleting EHPad nor token instructions. My assumption is that the instructions we wanted to

I did not observe any assertion. In addition, the documentation ( https://llvm.org/docs/LangRef.html#undefined-values) says: The string ‘undef’ can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. Undefined values may be of any type (other than ‘label’ or ‘ void’) and be used anywhere a constant is permitted. Either way,

Hi, I am trying to process the typeID from a type as follows: Type *T; if(T->isTokenTy()){ std::cout << "Token Type"; } /home/shehbaz/courses/ece1781/project/fslice/plugin/FSlice.cpp:147:14: error: ‘class llvm::Type’ has no member named ‘isTokenTy’ else if(T->isTokenTy()) ^ I am successfully able to do this for all other 20-25 types mentioned here:

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

MachineBasicBlock allows for multiple terminators. Unconditional branches and returns are marked as terminators; the MIPS backend also marks conditional branches as terminators. The MachineBasicBlock then has a helper function getFirstTerminator which iterates from the first terminator to the end of the MBB. So it seems to me that an MBB is a kind of superblock, single entrance and multiple side

What about SelectionDAG representation? Currently we expand callbr to INLINEASM_BR and BR. Both of which are terminators. But in order to support outputs we would need to put CopyFromReg nodes between them. ~Craig On Thu, Jun 27, 2019 at 12:18 PM Nick Desaulniers via cfe-dev < cfe-dev at lists.llvm.org> wrote: > + CBL mailing list > > > On Thu, Jun 27, 2019 at 11:08 AM Bill

+ CBL mailing list On Thu, Jun 27, 2019 at 11:08 AM Bill Wendling <isanbard at gmail.com> wrote: > [Adding the correct cfe-dev mailing list address.] > > On Thu, Jun 27, 2019 at 11:06 AM Bill Wendling <isanbard at gmail.com> wrote: > >> Now that ASM goto support has landed, Nick Desaulniers and I wrote up a >> document describing how to expand clang's

Within a basic block this is just normal iterator usage/manipulation: for (instr : llvm::make_range(FromInstruction.getIterator(), ToInstruction.getIterator())) { ... } Use std::next() on ToInstruction.getIterator() if you want it included. - Matthias > On Apr 9, 2018, at 10:04 AM, Alexandre Isoard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > Is there

Hello, Is there an iterator to iterate over a "range" of instructions in a Function? "range" meaning from an instruction::iterator up to an other instruction::iterator which either: - point to instructions in the same basic block (the first one first, second one second) - point to instructions in different basic block (the BB of the first dominate the BB of the second, and

"Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at lists.llvm.org> writes: >> On 2015-Oct-20, at 11:23, Reid Kleckner <rnk at google.com> wrote: >> >> I think the implicit iterator conversions are much less important >> now that we have range based for loops, but I still like having >> them. > > IMO, if a developer has an ilist iterator

I’ve been playing around with optimizing performance various passes and noticed something about ADCE: it keeps an Alive set that requires a lot of upkeep time-wise, but if each instruction had a /single bit/ of side data (to represent liveness, solely within the pass), the set wouldn’t be needed. I tested this out and observed a ~1/3 reduction in time in ADCE: 1454ms to 982ms according to a

On Mon, Sep 5, 2016 at 3:20 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Sun, Sep 4, 2016 at 1:06 PM, Simona Simona via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello, >> >> I'm trying to add a new instruction after a given instruction in a basic >> block. >> Until LLVM 3.7, I was using the following code:

I think the implicit iterator conversions are much less important now that we have range based for loops, but I still like having them. On Tue, Oct 20, 2015 at 11:13 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Oct-07, at 17:57, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > > I've been

Hi all, Recently I have implemented a transformation pass based on LLVM3.5 and its function is to duplicate the function's argument list in a bytecode file and replace all use of original function with modified function. In LLVM3.5, the pass can work properly. However, when I tried to transplant the pass to LLVM3.9, the error "Argument value does not match function argument type!"

Hello, I'm trying to add a new instruction after a given instruction in a basic block. Until LLVM 3.7, I was using the following code: BB->getInstList().insertAfter(I, new_inst); [where both I and new_inst are Instruction*] In LLVM 3.8 however, the SymbolTableList was created as a wrapper over iplist. Could anyone please tell me how I can do the same type of insertion in LLVM 3.8?

Why not just use Instruction::insertAfter()? I->insertAfter(new_inst); On Mon, Sep 5, 2016 at 8:13 AM, Ryan Taylor via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Try incrementing the iterator before using. > > On Sep 5, 2016 10:26, "Simona Simona via llvm-dev" < > llvm-dev at lists.llvm.org> wrote: > >> On Mon, Sep 5, 2016 at 3:20 AM, Daniel

> From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] > Sent: Wednesday, February 10, 2016 1:51 PM > To: Duncan P. N. Exon Smith > Subject: Re: [llvm-dev] Question about an error we're now starting to get on LLVM 3.8.0rc2since >> >> You're looking for r252380. Relevant excerpt: >> >> Note: if you have out-of-tree code, it should be

Hi, I am upgrading my project from 3.7 to 3.8. I find that following code used to compile in 3.7 but doesn't in 3.8 and I can't understand why. llvm::Function *mainFunc = ...; auto argiter = mainFunc->arg_begin(); llvm::Value *arg1 = argiter++; arg1->setName("obj"); But if I change the code to following it compiles: auto argiter = mainFunc->arg_begin(); llvm::Value

+llvm-dev > On 2016-Feb-09, at 12:54, Harris, Kevin <Kevin.Harris at unisys.com> wrote: > > Duncan, > Kevin Harris here, from Unisys. In our application, generating LLVM IR, we have several instances of code that looks like this: > > . . . > Value* pDS; > . . . > auto argIt = pFunc->arg_begin(); >

>Exceptions >All eh pads are grouped together regardless of their coldness and are part of the original function. There are outstanding issues with splitting eh pads if they reside in separate sections in the binary. This remains as part of future work. Can you elaborate more on the outstanding issues with splitting eh pads? From my dip into the unwind map in gcc_except_table the