search for: vr64

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:

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

...ster can live in multiple classes (cf. X86RegisterInfo.td where EAX and others are in GR32 and GR32_, though the comment says GR32_ is only for 32 bit mode, so it's not _really_ the case that it's in multiple classes). Does ValueType have something to do with that? In the same file, the VR64 register class has the following definition: def VR64 : RegisterClass<"X86", [v8i8, v4i16, v2i32, v1i64], 64, [MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7]>; So there are multiple ValueTypes here (the scalar registers each only have one corresponding to the b...

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

...t when a multi-typed RegisterClass is declared that > these bitconvert patterns between types in that class automatically > become legal. Is there a reason that TableGen shouldn't automatically > generate these patterns when a multi-typed register class is created? X86 backend has the VR64 and VR128 register classes which are exactly like this. Rather than adding a whole bunch of instruction selection rules to match all the possibilities. We've decided to ask the legalizer to normalize the target-independent nodes to one particular type. See X86ISelLowering.cpp: //...

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

...RegisterClass is declared that >> these bitconvert patterns between types in that class automatically >> become legal. Is there a reason that TableGen shouldn't automatically >> generate these patterns when a multi-typed register class is created? > > X86 backend has the VR64 and VR128 register classes which are exactly > like this. Rather than adding a whole bunch of instruction selection > rules to match all the possibilities. We've decided to ask the > legalizer to normalize the target-independent nodes to one particular > type. See X86ISelLowering.cp...

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.