similar to: BuildMI crashes on a certain probability on the exact same test

> On 2015-Apr-15, at 08:59, Reid Kleckner <rnk at google.com> wrote: > > Conventional wisdom, which is often wrong, says that bytes in Function are precious. In the past we've bent over backwards to put bits on Function and have DenseMaps in LLVMContexts and Modules. I think this is probably the *wrong* approach for debug info, which, when it's being used, is used

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340

Hello, I am editing the LowerTypeTests pass in LLVM, and part of my additions include the following 3 lines of code: // newTypeName is a std::string MDString* newMD = MDString::get(M.getContext(), newTypeName); ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD}; auto* node = MDTuple::get(M.getContext(), mdArray); Thus far, I have been developing on a version of Clang with

> On 2014-Nov-10, at 08:30, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 9, 2014, at 5:02 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> In response to my recent commits (e.g., [1]) that changed API from >> `MDNode` to `Value`, Eric had a really interesting idea [2] -- split >> metadata entirely from the `Value` hierarchy, and

I agree that the ArrayRef is likely the issue. I've debugged a crash caused by a temporary ArrayRef like that a couple times. Either do what David suggested or use a normal array: Metadata *mdArray[] = {ConstantInt::get(Int64Ty, 0), newMD}; ~Craig On Thu, Apr 30, 2020 at 9:56 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Apr 30, 2020 at

This patch adds EmitTypeAuxAttribute() function to CGDebugInfo, which allows other parts of clang issue auxiliary information through an enumeration type in Dwarf information. For example, by calling DI->EmitTypeAuxAttribute(type, "ID", 1234); We can get following information in dwarf: <1><3f>: Abbrev Number: 3 (DW_TAG_structure_type) <40> DW_AT_name

Why do these two guys take a pointer to the basic block, whereas all other BuildMI functions take a reference? They are not checking for null or anything and I didn't see any potential declaration conflicts. Am I missing something? Is there a reason for this? inline MachineInstrBuilder BuildMI(MachineBasicBlock *BB, DebugLoc DL,

Hi all, While I using BuildMI with MachineBasicBlock as parameter, I made a mistake. The mistake was that the MachineBasicBlock of instruction, which is for insertion, is different with given MachineBasicBlock as parameter. I have thought if there is assertion code to check whether MachineBasicBlocks are same between instruction's MachineBasicBlock and given MachineBasicBlock as

Hi all,Im writing a pass just before the register allocator in which  Im inserting a sequence of new instructions.I do this by calling subsequently for a number of times BuildMI.As a result I see that there is a dependency between the produced instructions which shouldnt be there as the instructions are not data dependent.Can anybody tell me how to avoid getting the dependency?thanks,Alex

On 03/22/2018 09:29 AM, Julius Hiller via llvm-dev wrote: > Hello everyone, > > I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. > To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. > I started with

Dear All, I am working on a x86 backend machineFunction pass, where I am trying to save the hard coded address of an arbitrary machine basic block to memory in ASM. I know the assembly needed for this but am lost at how to construct the BuildMI(). Note that these machine basic blocks are not entry's to a function. but in the middle of the function. so using addGlobalAddress or

Thank you for your help Tom you are totally right with the registers but the command you suggest also doesn't work. After some research I found the following thread on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110086.html With your help and the information about the condition codes I was able to resolve the error:         BuildMI(BB, BB.end(), DL,

Hello everyone, I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. I started with branch instructions:     const TargetMachine &TM = MF.getTarget();

> On Jun 23, 2018, at 10:14, Chris Lattner <clattner at nondot.org> wrote: > > > >> On Jun 23, 2018, at 9:11 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto:dexonsmith at apple.com>> wrote: >> >>> >>> I think we might be better off just reducing the pre-allocation size of most of our SmallVectors across LLVM and Clang.

Hi all, I’m trying to insert some add/sub and push/pop instructions in a MachineFunction pass for ARMv7-M. However, I encountered something weird. For an add, when I use BuildMI(….., TII->get(ARM::tADDi8), reg).addReg(reg).addReg(reg).addImm(imm). if reg is R0 - R7, everything is fine: I would get something like adds r1, 4 But if I use R8 - R12 as the reg in the BuildMI, I wouldn’t get

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A)

Sorry for not being specific enough. ARMv7-M includes Thumb and Thumb2. It has 12 regular registers (R0 - R12), and R8 - R12 are used. I can generate mov instruction that from/ R8-R12 to/from R0-R6. From this ARM page http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/ch03s03s01.html R9 - R12 have their conventional usage, but I don’t if this is the reason we cannot use them

Hi Craig, Thanks for the information. Can you point to the source that specifies tGPR to be R0 - R7? I tried to search in ARMInstrThumb.td but couldn’t find it. Thanks, - Jie On Apr 14, 2019, at 15:28, Craig Topper <craig.topper at gmail.com<mailto:craig.topper at gmail.com>> wrote: I believe there is probably a separate instruction in LLVM for thumb2 add. Probably starting with t2

Hello everyone, I'm a newbie of llvm. I'm trying to insert Intel MPX instruction BNDCU with BuildMI. I add my machinefunctionpass at addPreEmitPass2. Here is the code of insertion: BuildMI(MBB, MI, DL, TII->get(X86::BNDCU64rr)).addReg(X86::BND2, RegState::Define).addReg(X86::R10); And here is to stack track when I compiler program with modified llc:

TL;DR: If you use metadata (especially if it's out-of-tree), check the numbered list of lost functionality below to see whether I'm trying to break your compiler permanently. In response to my recent commits (e.g., [1]) that changed API from `MDNode` to `Value`, Eric had a really interesting idea [2] -- split metadata entirely from the `Value` hierarchy, and drop general support for