similar to: X86 new registers not being allocated

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

Here is a series of patches replacing EVT with MVT at a number of places in TargetLowering. The last two patches are related cleanups in SelectionDAGBuilder. /Patrik Hägglund > git log --stat --reverse origin/master.. commit 8dabe3eb005360347eabb86a2e88c3b6e9098ed5 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:37:37 2012 +0100 Change

I added one method which clears the list of register classes. Then there is a change to mips16 code which simulates switching from mips32 to mips16 mode in the same module. It seems to work fine in that I can run this version of llvm for mips16 and it works identical to the one without this code. Beyond the "make check" I have run test-suite against this version. We could just

Hello, I'm new to this mailing list and fixing llvm bugs for Android. Can anyone point me to any previous discussion or work related to the following bug? https://llvm.org/bugs/show_bug.cgi?id=23897 I am testing my patch to llvm to make f128 values stay in SSE registers instead of being split into two i64 values. I have tried to add a register class FR128 to hold f128 values for the x86_64

Hello Matthias, On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote: > It's not that hard in principle: > - A register class is a set of registers. > - Virtual Registers have a register class assigned. > - If you have register constraints (like x86 8bit operations only work on > al,ah,etc.) then you have to create a new register class to express that.