search for: machinesdnodes

Hi all, I need to figure out why InstrEmitter::EmitMachineNode assumes that when the number of outputs of a MachineSDNode is greater than the number of defs in the corresponding MCInstrDesc, the outputs in the difference will be placed into physical registers as opposed to virtual registers. The specific line in question is: bool HasPhysRegOuts = NumResults > NumDefs &&

On Nov 9, 2011, at 2:12 PM, Chris Lattner wrote: > On Nov 9, 2011, at 1:08 PM, Jim Grosbach wrote: >>> On Nov 9, 2011, at 10:49 AM, Jim Grosbach wrote: >>>>> >>>>> It's not good, but people do it. Also constructing enums via & and | etc. It'd be nice to be able to get the name of whatever it is that the code generator actually produced :)

Hi, During instruction selection, I have the following code for certain LOAD instructions: const LoadSDNode *LD = cast<LoadSDNode>(N); SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions

Hi Jochen, > My llvm version is 3.0 release. > I have a module generated by clang. When I optimize it, I first add an > inlining pass (llvm::createFunctionInliningPass), then these passes: > - own FunctionPass > - llvm::createPromoteMemoryToRegisterPass > - llvm::createInstructionCombiningPass > - llvm::createDeadInstEliminationPass > - llvm::createDeadStoreEliminationPass

Hi! My llvm version is 3.0 release. I have a module generated by clang. When I optimize it, I first add an inlining pass (llvm::createFunctionInliningPass), then these passes: - own FunctionPass - llvm::createPromoteMemoryToRegisterPass - llvm::createInstructionCombiningPass - llvm::createDeadInstEliminationPass - llvm::createDeadStoreEliminationPass - new llvm::DominatorTree() - new

Hi Quentin, Thanks, that explanation makes sense. I can see that in a normal register machine, implicitly defs must be physical registers. In a stack machine like WebAssembly, though, implicit defs are known to be pushed onto the value stack just like any other defs. Slots on the value stack are represented by virtual registers until stackification, so for WebAssembly we do need the implicit defs

...rn values, this approach would require generating billions of Instructions in TableGen. So that won't work. The other approach is to have just one call instruction that has variadic outputs as well as inputs. This is the approach I am pursuing now, and I have it working through the lowering to MachineSDNodes, but the approach is breaking down in the InstrEmitter because it is trying to use physical registers. WebAssembly is a stack machine, so all instructions including calls push their results onto the value stack as opposed to placing them in registers. The value stack is not in memory and not addre...

Hello everyone, I am working on some changes to the Hexagon VLIW PreRA scheduler, and as a part of it need to test aliasing properties of two instruction. What it boils down to is the following code: char a[20]; char s; char *p, *q; // p == &a[0]; q == &s; void test() { register char reg; s = 0; reg = p[0] + p[1]; s = q[0] + reg; return; } When I ask the question whether

Hello. I expand an instruction to a sequence of MachineSDNodes at instruction selection, in the Select() method of the SelectionDAGISel class. For efficiency, in order to generate fewer instructions, I would like to assign twice to the same physical register - but since I don't want to "mess" with the register allocator, I am using only v...

...would > require generating billions of Instructions in TableGen. So that won't work. > > The other approach is to have just one call instruction that has variadic > outputs as well as inputs. This is the approach I am pursuing now, and I > have it working through the lowering to MachineSDNodes, but the approach is > breaking down in the InstrEmitter because it is trying to use physical > registers. > > WebAssembly is a stack machine, so all instructions including calls push > their results onto the value stack as opposed to placing them in registers. > The value stack i...

Hi Christian, Ryan just reported to me that llvm-3.4 is no longer building on OS X Leopard (https://trac.macports.org/ticket/41548). It seems the issue is with a commit that you made back in April (referenced below) which added this to SIISelLowering.cpp: // Adjust the writemask in the node std::vector<SDValue> Ops; Ops.push_back(DAG.getTargetConstant(NewDmask, MVT::i32)); for

On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > Hi, > > During instruction selection, I have the following code for certain > LOAD instructions: > > const LoadSDNode *LD = cast<LoadSDNode>(N); > SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); >

Can't you just use &Ops[0] ? On Tue, Nov 26, 2013 at 12:03 PM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote: > Hi Christian, > > Ryan just reported to me that llvm-3.4 is no longer building on OS X Leopard (https://trac.macports.org/ticket/41548). It seems the issue is with a commit that you made back in April (referenced below) which added this to

I am implementing a new backend and am pretty sure I don't quite understand "the way" one is supposed to implement conditional branches. My target CPU natively supports a conditional branch instruction that accepts a condition to test (equal, less than, etc.), two operands (two registers, or one register and one immediate), and finally a target PC to branch to if the comparison

On Nov 26, 2013, at 1:41, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Can't you just use &Ops[0] ? Is that safely portable? ie is it required that pre-C++11 std:vector be implemented such that the data is stored contiguously in a realloc'd array? While I'm not sure anyone would do this (so perhaps the point is moot), it seems that one could use

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of

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

Hello. I am using the post-RA (Register Allocation) scheduler to avoid data hazards by inserting other USEFUL instructions from the program (besides NOPs) and it breaks apart some sequences of instructions which should remain "glued" together. More exactly, in my [Target]ISelDAGToDAG.cpp it is possible that I replace for example a BUILD_VECTOR with a machine SDNode called

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0