similar to: [LLVMdev] Need Advice on AVX

On Tuesday 24 November 2009 12:57, David Greene wrote: > So I can mark it as not legal but how should it be lowered? I can't > bitcast to a v2i64 because the vector sizes are different. I could > do an extract_subreg and then write a pattern to match that to MOVQ. What does this mean? def MOVSX16rr8 : I<0xBE, MRMSrcReg, (outs GR16:$dst), (ins GR8 :$src),

Hello, David > How does ${dst:subreg32} work? This is just modifier provided to asmprinting code. Here, it seems, 16 bit register is passed to asmprinter, but it sees modifier and grabs 32-bit superreg. > Can one do the same for sources? Yes, this is just modifier for printing, nothing more... > Is it preferable to use the source modifier or write an EXTRACT_SUBREG > pattern

On Tuesday 24 November 2009 14:12, Anton Korobeynikov wrote: > Hello, David > > > How does ${dst:subreg32} work? > > This is just modifier provided to asmprinting code. Here, it seems, 16 > bit register is passed to asmprinter, but it sees modifier and grabs > 32-bit superreg. > > > Can one do the same for sources? > > Yes, this is just modifier for printing,

Hi, I am wondering how to specify the selection DAG patterns for instructions that use accumulator. For example multiply-accumulate instruction with one destination operand and two source operands: mac $dst, $src1, $src2 ;; $dst += $src1*$src2 Seems that it has a cycle in the pattern. So how do I specify it in the DAG? There are a few instructions in the ARM backend like this one, but the

Hi, This patch fixes outs/ins of MOV16mr instruction of X86. Thanks. diff --git a/lib/Target/X86/X86InstrInfo.td b/lib/Target/X86/X86InstrInfo.td index e9a0431..f5b2064 100644 --- a/lib/Target/X86/X86InstrInfo.td +++ b/lib/Target/X86/X86InstrInfo.td @@ -1412,7 +1412,7 @@ let SchedRW = [WriteStore] in { def MOV8mr : I<0x88, MRMDestMem, (outs), (ins i8mem :$dst, GR8 :$src),

Hi, I'm trying to implement a new backend for an embedded CISC processor. Therefore I thought that it makes sense to take X86 target as a basis, to save some time. But when I look into the X86InstrInfo.td, I have a very strong feeling that it is one of the most complex instruction set descriptions compared to other targets. I can imagine that this is due to the complexity of X86's

Hi I'm returning to my MC6809 back-end from a health-related hiatus. The assembler is tantalisingly close, but I've got some parsing and matching problems. The register set; these overlap in annoying ways, for instance, two instructions TFR and EXG each have a single opcode, and the post-byte specifies which registers are to be involved, but the registers can be 8- or 16-bit, and 2 of

On Sun, 1 Oct 2006, Roman Levenstein wrote: > I'm trying to implement a new backend for an embedded CISC processor. > Therefore I thought that it makes sense to take X86 target as a basis, > to save some time. Ok. Note that the X86 backend is one of the most complex though, because it supports several subtargets and ABIs, which makes it more complex than some other targets. >

>I am assuming a 16-bit value will be stored in a pair of 8-bit > registers? One related question is how to make sure that the correct register pair is allocated to the16-bit quantity when using two 8-bit operations. In other words, how we can make sure that the 16-bit pointer is stored into [AH, AL] and not in [AH, BL] ? i.e. GR8 = [ AH, BH, AL, BL]; GR16 = [AX, BX] ; // AX, BX

Hello. I write backend for Z80 cpu and I have some trouble with lowering load/store nodes to different machine opcodes. Some target instructions work with specified registers (not all registers in RegisterClass). Often it's one or two registers. I don't understand how use ComplexPattern in this case. But if I don't use ComplexPattern I'll have other problems - not all

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it

I am assuming a 16-bit value will be stored in a pair of 8-bit registers? If so, add pseudo register which represent pairs of 8-bit registers. Add them to a pseudo register class. This allows you to mark i16 "legal". The difficult part is then to figure out how to lower these 16-bit operations into 8-bit ones. You probably need to custom lower a bunch of them with target

Hi All, I've developed a pass to render machine functions as HTML pages with some accompanying information about liveness and register pressure. Current features: Renders machine functions, optionally displaying estimated register pressure for selected register classes, and liveness for selected intervals. The following command line options can be used to enable and customise the

I am working on a project where we are integrating an existing pre-RA scheduler into LLVM and we are trying to match our peak register pressure values with the machine instruction schedulers values while using X86. I am finding some mismatches in test cases like the one attached. The registers "AH" and "AL" are live-out but not live-in and I don't see that they are defined

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Bill Wendling > Sent: Friday, September 19, 2008 4:38 AM > > On Thu, Sep 18, 2008 at 7:12 AM, <Sachin.Punyani at microchip.com> wrote: > > What changes would be required in LLVM to support illegal pointer type? > > > Hi Sachin, >

I'm working on defining the instructions and implementing the lowering code for a Z80 backend. For now, the backend supports only the native CPU-supported datatypes, which are 8 and 16 bits wide (i.e. no 32 bit long, float, ... yet). So far, a lot of the simple stuff like immediate loads and return values is very straightforward, but now I got stuck with ISD::TRUNCATE, as in:

Hi Chris, Thanks a lot for your answer! Chris Lattner wrote: >> 1. Why does X86 instruction set description provide different >> descriptions for the same instructions, which differ only in the size >> of operands? >> E.g. >> >> def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), >> "mov{b} {$src, $dst|$dst, $src}",

Tracking down a problem with one of our benchmark codes, we've discovered that some of the patterns in X86InstrX86-64.td are wrong. Specifically: def MOV64toPQIrm : RPDI<0x6E, MRMSrcMem, (outs VR128:$dst), (ins i64mem:$src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(set VR128:$dst, (v2i64 (scalar_to_vector

On Nov 24, 2009, at 12:19 PM, David Greene wrote: > On Tuesday 24 November 2009 14:12, Anton Korobeynikov wrote: >> Hello, David >> >>> How does ${dst:subreg32} work? >> >> This is just modifier provided to asmprinting code. Here, it seems, 16 >> bit register is passed to asmprinter, but it sees modifier and grabs >> 32-bit superreg. >>

Hi everyone, I am puzzled by several instruction defines in MSP430. 1 def MOV16rr : Pseudo<(outs GR16:$dst), (ins GR16:$src), "mov.w\t{$src, $dst}", [ ]>; Because it's an empty dag pattern[ ], by what does instuction selector select intruction 'MOV16rr'? 2 let canFoldAsLoad = 1, isReMaterializable = 1, mayHaveSideEffects =