similar to: CopyToReg node

Hi all, I have a bunch of new registers set up in X86RegisterInfo.td, the important part being def PR128 : RegisterClass<"X86", [i128], 128, (sequence "POI%u", 0, 7)>; def VR128 : RegisterClass<"X86", [v4f32, v2f64, v16i8, v8i16, v4i32, v2i64], 128, (add PR128, FR32)>; I have an entry in

Hi, I have a set of new registers for x86 which I defined in X86RegisterInfo.td to be: def POI0: X86Reg<"poi0", 0>; def POI1: X86Reg<"poi1", 1>; def POI2: X86Reg<"poi2", 2>; def POI3: X86Reg<"poi3", 3>; def POI4: X86Reg<"poi4", 4>; def POI5: X86Reg<"poi5", 5>; def POI6: X86Reg<"poi6",

Hi, I've been trying to teach LLVM that pointers are 128-bit long, which segfaults with some seemingly unrelated stacktrace when I try to take an address of a variable. Since stack saving and loading seems to work fine, I dare to assume the instruction causing problems there is leaq. Now I've done a search for leaq of the entire LLVM codebase with no success and I'd like to know which

Hi, I would like to wrap some of the library functions such as malloc() into for example: malloc_wrapper(int size) { malloc(size+4); //call the real malloc here } and have all uses of malloc replaced with malloc_wrapper. Is there a way to do that? -- ---------------- Barbora Murinová The University of Edinburgh SK: +421905718390 <+421%20905%20718%20390> UK: +447477833795

Hi all, the backend data layout string is generated in X86TargetMachine.cpp. As far as I understand, however, that is not the only place where the target description string is generted. Where does the expected target description string come from? Thanks! -- ---------------- Barbora Murinová The University of Edinburgh SK: +421905718390 UK: +447477833795 -------------- next part --------------

Hi all, I've got a few new registers and I've extended the pointer size to be 128 bits. For allocas, that is done by adding another SelectionDAG after FrameIndex that extends it to 128 bits. That seems to work okay, except that the final representation throws in additional instructions. For example for a piece of code such as: int a; int* pointer = &a; it returns pushq %rbp

Hi all, I've been trying to extend pointer size of the X86 target to 128 bits. For the prortype, I would like nothing more than the pointers being i128 type with the same value as before. All I've done was changing the data layout string to p:128:128 and when trying to run a basic program such as: int a = 42; int *p = &a; it segfaults with the following stack trace: #0

Hi all, I'm trying to simulate an extended x86 architecture on gem5 with several new instructions. My hardware setup is done and now I'd like llvm to accept the existence of the new instruction passed in inline assembly and output the correct opcode and registers. I chose the two-byte opcode 0x0F 0x7A and I would like the instruction to have the same operands and return values as CVTPS2PI

On Jun 25, 2009, at 2:05 PM, Artjom K. wrote: > > Greetings, > > I am rather new to LLVM, so please excuse my limited knowledge about > it. > > Currently I am trying to modify the X86TargetLowering::LowerCALL > method by > inserting additional instructions before the call. > As far as I understand, nodes are created by calling the getNode > method on >

Hi Tim, Tim Northover-2 wrote > The code used for DIV is around X86ISelDAGToDAG.cpp:2415, but from a > glance the key points seem to be: > 1. use the second result of getCopyToReg (i.e. SDValue(setIdNode, 1)) > in the RDMSR node. > 2. Give your RDMSR node type MVT::Glue instead of MVT::Other I tried doing what you said, and the DAG looks like how I think it supposed to look like

Thank you for your help. I think I managed to create the instruction I wanted: // mov eax, 41 Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); I don't understand though what InFlag is for. As I read the code, it even remains uninitialized when first passed to some node creation method.

On Jun 26, 2009, at 4:49 AM, Artjom K. wrote: > > Thank you for your help. > > I think I managed to create the instruction I wanted: > > // mov eax, 41 > Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), > DAG.getConstant(41, MVT::i32), InFlag); > InFlag = Chain.getValue(1); > > I don't understand though what InFlag is for. As I read the

On Tue, 30 May 2006, [UTF-8] Rafael Esp?ndola wrote: > I have changed the way in which the ARM backend generates a function > return. Instead of expanding a RET to a CopyToReg;RETFLAG, it now > expands into a CopyToReg;BRIND. I haven't commit it yet, but the patch > is attached. Ok, I haven't looked at the code, but you're free to do whatever make sense. > In my

In my target I want to have mem-mem operations. But PHI instructions use virtual registers and gets converted to a series of CopyFromReg and CopyToReg instructions. These DAGs end up using physical registers. My first approach was to spill the virtual register to force a mem-mem operation. But I was unable to do this using LowerOperation() and setOperationAction(ISD::CopyToReg, MVT::i32, Custom);

Hmm, okay. Then what's the problem being reported here? I'm not sure what I'm supposed to do with "LLVM ERROR: Cannot select: t1: i16 = Constant<127>".BTW, the function is: ; ModuleID = 'return.c' source_filename = "return.c" target datalayout = "E-m:e-p:16:16:16-i1:16:16-i8:16:16-i16:16:16-i32:16:16-i64:16:16-S16-n16" target triple =

Thanks to your help I've actually made some progress... Especially the SelectionDAGNodes.h was a good hint. But there are still some things that I can't figure out: // 'mov eax, 41' Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); // 'inc eax' SDValue eaxVal =

So there's a DAG that looks like this in the debug output: Selecting: t3: ch,glue = CopyToReg t0, Register:i16 %R5, Constant:i16<127> In the instruction selection phase, what pattern would that match? I've constructed this so far: (??? REG16:$dst, i16imm:$src) but the problem is, I can't determine what to use as ???. There is an ISD::CopyToReg enum value, but I don't

Well, that's the thing: I thought that was CopyToReg. I don't know what the name of the node is to load one value into a register, so I don't know how to construct such a pattern. On Sat, Nov 4, 2017 at 9:23 PM Craig Topper <craig.topper at gmail.com> wrote: > Do you have a pattern for loading an i16 immediate into a 16-bit register? > > ~Craig > > On Sat, Nov 4,

I have changed the way in which the ARM backend generates a function return. Instead of expanding a RET to a CopyToReg;RETFLAG, it now expands into a CopyToReg;BRIND. I haven't commit it yet, but the patch is attached. In my opinion the resulting code is easier to understand, but I have some questions: Why all backends use RETFLAG? Why it is named RETFLAG? Why the Copy that places the

Hey, I wanted to add an intrinsics to read MSRs. So I added the intrinsics and lowered it to a new ISD node I created ISD::RDMSR, its first operand is the MSR id. I added a case in X86DAGToDAGISel::Select for ISD::RDMSR. Now I know rdmsr works like so: mov r/ecx, <id> rdmsr r/eax holds the lower 32/64 bit >From what I understood this needs a Token Factor node, nodes which are