similar to: question: access IR class Instruction from DAG SDValue

I am working on llvm gpu backend. The instruction metadata can only get in IR (class instruction). In DAG stage, the instructions are reordered, so I cannot map the metadata to correct instruction if I cannot access instruction from DAG or MachineInstr structure. > On Nov 26, 2017, at 11:02 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > It might be a more useful to know what

Seems llvm cannot pass metadata to MachineInstr, or setting operand description in class Instruction and pass to class MachineInstr. Is it a good idea to extend llvm kernel structure to having this feature? Jonathan > On Nov 27, 2017, at 9:01 PM, Jatin Bhateja <jatin.bhateja at gmail.com> wrote: > > SelectionDAGBuilder contained within SelectionDAGISel has a map (NodeMap) b/w

Hello. I generated in the back end by hand (in C++ code, not with TableGen) some fancy assembly code using Inline ASM expressions and if I use 2 functions in my source code (but NOT just 1 function; I will not present the functions, but each requires me to generate an Inline ASM expression) I get this error at compilation (at scheduling): BB#0: derived from LLVM BB %entry

Hi, > Today I've been trying to debug a weird bug that makes JIT crash with > certain code and when using the inliner. This may sound weird, but if I > disable the inliner, it doesn't crash. > I include an example gdb dump below. Does something looks wrong? Do you > think it's a bug in JIT or it's just some other piece of code that is > writing on the JIT

Hi, Today I've been trying to debug a weird bug that makes JIT crash with certain code and when using the inliner. This may sound weird, but if I disable the inliner, it doesn't crash. I include an example gdb dump below. Does something looks wrong? Do you think it's a bug in JIT or it's just some other piece of code that is writing on the JIT memory?.. I don't really know

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

Hi, I'm trying to implement __builtin_setjmp / __builtin_longjmp for Sparc processors. I think I'm very close, but I can't work out how to issue BuildMI-type instructions to load the address of the recovery location (set in setjmp) into a register using the SETHI / OR combination. I can't see any equivalent code anywhere else in Sparc. I imagine this is similar if I try to make a

On Monday 13 July 2009 13:13, Chris Lattner wrote: > > We're not going to submit our line number stuff anyway (it's too > > much of a > > hack) but we would like the comment infrastructure to be there. > > DebugLoc is there. The transition isn't complete at the LLVM IR > level, but it is at the MachineInstr level AFAIK. Well, the IR level is pretty

On Mon, Jun 6, 2016 at 8:32 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It is not a keyword. It is a node defined in > include/llvm/Target/TargetSelectionDAG.td. You can likely find most of the > definitions you're wondering about there. > In terms of its purpose, perhaps someone can elaborate on that a bit more, > but there is no corresponding

hi Devang and thanks for the tips, i finally managed to fit all the pieces together into something that seems to work. It's probably not the best (or even correct!) way of doing it but here's a brief overview for reference: An instruction in the LLVM IR gets converted into an SDNode in the DAG then later into a MachineInstr. I'd already attached my own MDNodes to IR instructions I

Hi Roger, On Mon, Aug 23, 2010 at 4:01 PM, Roger Wang <innit42 at gmail.com> wrote: > Dear all, > > I'd like to find the memory location of certain instructions in a > compiled/linked binary. During the IR phase, I tag instructions I'm > interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable > ID). I'd now like to propagate that data

Dear all, I'd like to find the memory location of certain instructions in a compiled/linked binary. During the IR phase, I tag instructions I'm interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable ID). I'd now like to propagate that data to the assembly via a custom DWARF tag I attach to each X86 instruction created from a tagged IR instruction. This will

On Monday 13 July 2009 11:40, Chris Lattner wrote: > > I was attempting to reduce the number of files affected, but if you > > want this change I'll go ahead and do it. > > Makes sense, thanks. Please do it as a separate patch from the other > changes though since it will be large and mechanical. Ok, no problem. > > - Tag instructons with source line information

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

On Jul 13, 2009, at 10:02 AM, David Greene wrote: >>> - Tag instructons with source line information (customers really >>> want this). >> >> Right, that would be nice. This should be synthesizable from the >> DebugLoc on the instruction in the asm printer, no need to >> redundantly >> encode it into the comment field. > > Except the DebugLoc

Since 2.7 is getting close to code freeze, I'd like to see if I can get in our changes to track non-temporal memory operations into trunk. As discussed earlier, I was hoping to do this via metadata. It's pretty clear how to attach the data to Instructions, but after that, I'm not sure what happens. Somehow we have to carry this all the way back into MachineInstrs. What happens to

Hi Tom, Matt, I'm running into strange issues with the cos test (piglit generated_tests/cl/builtin/math/builtin-float-cos-1.0.generated.c) I have been seeing random failures (incorrect results) for some time and tried to investigate. the weird part is that the failures are not 100% reproducible, sometimes the tests pass, or partly pass (it's usually float8 and float16 subtests that

Right now the MemSDNode keeps a volatile bit in the SubclassData to mark volatile memory operations. We have some changes we'd like to push back that adds a NonTemporal flag to MemSDNode to mark instructions where movnt (on x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added another flag to the MemSDNode

Hello, Duncan. > 3-fortran.diff > Get fortran to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't