similar to: LEAQ instruction path

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 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'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

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 having some trouble with x86 generating some CopyToReg nodes with a null 2nd operand. I've done an extensive search of the entire codebase and found that all creation of CopyToReg nodes happens at SelectionDAG.h, eventually, but my debug messages did not register a call to either of the three getCopyToReg methods it provides. Is there any other place where CopyToReg nodes get

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 ! I'm trying to modify the code in a machine function pass… I added a new basicblock and I want to add a jump to an another BB from my new BB. Here is my code : bool Obfuscation::runOnMachineFunction(MachineFunction &MF) { MachineBasicBlock *newEntry = MF.CreateMachineBasicBlock(); MF.insert(MF.begin(), newEntry); std::vector<MachineBasicBlock*> origBB;

I had been assuming that give a LiveRange a, a.valno->def, if valid, would be the same as a.start. But this is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr

I want to write a pattern that looks something like this: def : Pat<(unalignedstore (v2f64 VR128:$src), addr:$dst), (MOVSDmr ADD64ri8(addr:$dst, imm:8), ( SHUFPDrri (VR128:$src, (MOVSDmr addr:$dst, FR64:$src))), imm:3) So I want to convert an unaligned vector store to a scalar store, a shuffle and a scalar store. There are several question I have: - Is the imm:3 syntax

On Jan 16, 2008, at 11:49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill>

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: >> > Yeah, the function attributes section of LangRef is a reasonable place >> > to >>

On Monday 17 November 2008 14:28, David Greene wrote: > I want to write a pattern that looks something like this: > > def : Pat<(unalignedstore (v2f64 VR128:$src), addr:$dst), > (MOVSDmr ADD64ri8(addr:$dst, imm:8), ( SHUFPDrri (VR128:$src, > (MOVSDmr addr:$dst, FR64:$src))), imm:3) > > So I want to convert an unaligned vector store to a scalar store, a

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I

Hi, I'm having some trouble wirting an instruction in the X86 backend. I made a new intrinsic and I wrote a custom inserter for my intrinsic in the X86 backend. Everything works fine, except for one instruction that I can't find how to write. I want to add this instruction in one of my machine basic block: mov [rdi], 0 How can I achieve that with the LLVM api? I tried several

Hi LLVMers, I have finally sorted out licensing issues and found some time, so I'm trying to port my PBQP register allocator to 2.4 in order to contribute it (if you want it). I've run into a bug that has me confused though. I'm currently failing the following assertion: llc: VirtRegMap.cpp:1733: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&,

Hi Scott, That #1073741833 is a register mask. They are treated as aggregate registers (essentially sets of registers), so if it includes R9D and R11D, it will be treated as being aliased with both. These separate defs are there because they reach disjoint registers. -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development From: Scott

Hi Scott, Sorry for the late reply, I was out of office during the holidays. 1. A def node can reach either a use node, or another def node. In the highlighted phi node (p3224), the def (d3225) reaches another def (1598) in statement (s1597), that’s why it’s needed. 2. The reason why the def of R11 in s1578 is not connected directly to the use in s1725 is that there may be an intervening

On Sep 3, 2008, at 5:58 AM, Lang Hames wrote: > Hi LLVMers, > > I have finally sorted out licensing issues and found some time, so I'm > trying to port my PBQP register allocator to 2.4 in order to Nice! We would definitely welcome your contribution. > > contribute it (if you want it). I've run into a bug that has me > confused though. > > I'm currently