similar to: New x86 instruction with opcode 0x0F 0x7A

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

0x0f 0x6f 0xc8 And 0x0f 0x7f 0xc1 Should both be movq % mm0, % mm1. (AT&T) However, llvm 3.4 at least does not recognise the second variant as being a valid instruction. We are currently compiling up latest src incase it has been fixed. If not, could someone take a look or recommend how to fix? Lee -------------- next part -------------- An HTML attachment was scrubbed... URL:

How do I get the TargetRegisterClass for a physical register? SSARegMap::getRegClass only works for virtual registers. -Dave

Take a look at getPhysicalRegisterRegClass( const MRegisterInfo *MRI, MVT::ValueType VT, unsigned reg) in ScheduleDAG.cpp. -- Christopher Lamb On Jun 18, 2007, at 4:52 PM, David A. Greene wrote: > How do I get the TargetRegisterClass for a physical register? > SSARegMap::getRegClass only works for virtual registers. > >

On Monday 18 June 2007 19:02, Christopher Lamb wrote: > Take a look at getPhysicalRegisterRegClass( > const MRegisterInfo *MRI, > MVT::ValueType VT, > unsigned reg) > > in ScheduleDAG.cpp. Yuck. I was afraid of that. What is the ValueType needed for? Isn't the register id itself an indication of the ValueType it represents? Where I'm at I

Hi, I'm looking at scalar and packed instructions in X86. The instruction VCOMISS is scalar. May I remove SSEPackedSingle/SSEPackedDouble domain from it? defm VUCOMISS : sse12_ord_cmp<0x2E, FR32, X86cmp, f32, f32mem, loadf32, "ucomiss", SSEPackedSingle>, TB, VEX, VEX_LIG; defm VUCOMISD : sse12_ord_cmp<0x2E, FR64, X86cmp, f64,

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 All, I'm working on a back end for an architecture that makes use of multi- typed register classes. def MR: RegisterClass<"namespace", [type1, type2, ... ], ... > When running some preliminary tests I found that the instruction selector refused to select certain ops (specifically stores) for some instructions when the operand type wasn't the first type for the

On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > > selector refused to select certain ops (specifically stores) for some > instructions when the operand type wasn't the first type for the > register class. After some digging around I seem to have solved the > problem by creating bitconvert patterns between the types in the > register class like the following: > >

I was trying to install Ubuntu 7.10 on an HVM domain, when when the install kept hanging at a particular point. xm dmesg shows the following : (XEN) realmode.c:132:d28 Failed to emulate insn. (XEN) realmode.c:174:d28 Real-mode emulation failed @ 0000:00007f34: 0f 2c 06 08 6b 04 (XEN) domain_crash called from realmode.c:175 (XEN) Domain 28 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-3.4-unstable

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.

Ok, so I've been chugging away at AVX and added some new features in TableGen to facilitate writing generic patterns. Here's an example: //===----------------------------------------------------------------------===// // Dummy defs for writing generic patterns //===----------------------------------------------------------------------===// def SRCREGCLASS; def DSTREGCLASS; def MEMCLASS;

On Feb 12, 2007, at 12:58 PM, Evan Cheng wrote: > > On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > >> >> selector refused to select certain ops (specifically stores) for some >> instructions when the operand type wasn't the first type for the >> register class. After some digging around I seem to have solved the >> problem by creating bitconvert

First let me introduce myself: Sr Computer Scientist 20+ yrs SW/HW development Audio Rookie < 60 days Intel based computer Soundblaster 128 PCI Linux Fedora Core 2 ALSA - Advanced Linux Sound Architecture ALSA provides the audio and MIDI functionality to the Linux operating system as of Fedora Core 2 and is the future of Linux (so I have been told) http://www.alsa-project.org/ I have read