similar to: Question about pattern matching process

In an attempt to add vector registers to my target, I ran into a problem. LLVM started to complain about not being able to infer types from the provided DAG patterns for several classes of instructions. After a discussion on the llvm-dev mailing list and IRC channel the recommendation was to make DAG patterns for these classes of instructions more specific. Which is what was done. However after

Thank you. i understood how avx512 vector instructions are written in x86instravx512. i need to define my vector instructions so i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))],

Thank you; i have changed as follows.is it fine now? def VADD_256B : I<0xFE, MRMDestReg, (outs VR2048:$dst), (ins VR2048:$src1, VR2048:$src2), "VADD_256B\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (add VR2048:$src1, VR2048:$src2))]]>; Also here i have changed class RI to I. Does it make any difference? On Sat, Jul 8, 2017 at 9:38 AM, Craig Topper

Thank You. I have seen the opcode is 8 bits and all the combinations are already used in llvm x86. Now what to do? On Sat, Jul 8, 2017 at 10:57 AM, Craig Topper <craig.topper at gmail.com> wrote: > Yes its an opcode conflict. You'll have to look through Intel documents > and find an unused opcode. I've only added instructions based on a real > spec so I don't know

Thanks Anton and Krzysztof! Here is the dump using the -debug flag. At this point I am not making much sense of this, would it be too much to ask if one of you could walk me through one of these lines? One thing that I didn't point out is that I never defined any separate floating point registers, not sure if this will pose any issue? Thanks again for your time! Jeff jeff at

I am working on an experimental target and trying to make sure that the load offset field is used to the best way. There appears to be some control over the architecture's offset range and whether the offset is too large and needs to be lowered/converted into a separate sequence of operations in DAGSelection? Can someone point me to what might be the case? For example, the difference between

On Fri, Feb 19, 2016 at 6:10 AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/18/2016 6:01 PM, Rail Shafigulin via llvm-dev wrote: > >> [(set SR:$rD, (Esenciasetflag (i32 GPR:$rA), (i32 >> immSExt16:$imm), (i32 Cond)))]> { >> > > I suspect that the "set SR:$rD" is the problem here. The Esenciasetflag

Hello. Could you please help me solve the following LLC bug happening at instruction selection time: ISEL: Starting pattern match on root node: t172: ch = store<ST64[FixedStack6]> t0, t6, FrameIndex:i64<6>, undef:i64 Initial Opcode index to 157 Skipped scope entry (due to false predicate) at index 162, continuing at 236 Match failed at

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 Quentin, >> Yes, the dags in view-isel-dags and view-legalize-types-dags are correct (the add operations are here and are their results are used) and the dags are the same. > > And what about view-sched-dags? The DAG looks like I described below (*) > This one should give you what has been selected. So if this is not correct, you have indeed a problem in the selection

At one point someone showed me how to view the output of how instruction selection is happening. The output I'm talking about is shown below. Can someone remind me how to generate it? (I really should start writing down stuff like this) ========================= Orignal Match Result ===================================== Selecting: 0x2ebfa78: glue = EsenciaISD::SET_FLAG 0x2ebee18, 0x2ebef20,

Hi there, I am currently trying to create an LLVM Backend for a RISC architecture and running into problems with setCC and brcond. First a few explanations: The architecture doesn't have a dedicated flag register, but seven 1-bit-wide so called "condition registers", c0-c6, which can be set by e.g. a compare instruction: > cmp ne, c0, r1, 123 It also supports conditional

also i further run the following command; llc -debug filer-knl_o3.ll and its output is attached here. by looking at the output can we say that legalization runs fine and the error is due to instruction selection/ pattern matching which is not yet implemented? so do i need to worry and try to correct it at this stage or should i move forward to implement instruction selection/ pattern matching?

Have you read http://llvm.org/docs/WritingAnLLVMBackend.html and http://llvm.org/docs/CodeGenerator.html ? http://llvm.org/docs/WritingAnLLVMBackend.html#instruction-selector describes how to define a store instruction. -Eli On 7/6/2017 6:51 PM, hameeza ahmed via llvm-dev wrote: > Please correct me i m stuck at this point. > > On Jul 6, 2017 5:18 PM, "hameeza ahmed"

Hello. I'm writing a back end for a RISC processor (similar to BPF) with a large SIMD unit. I tried in the last days to make llc compile to SIMD code the following LLVM program: define i32 @foo(i32* %A, i32* %B, i32* %C, i32 %N) #0 { entry: ;vector.body: ; preds = %vector.body, %vector.body.preheader.split.split %0 = getelementptr inbounds i32, i32* %A, i64 0 ; i64 %index ; Alex: I

Hello, Tim, Thank you for your advice. Indeed, the problem with "LLVM ERROR: Cannot select" was a false predicate that should have been true. I solved the problem by simply making the C++ function implementing the TableGen predicate used in my store instruction (very similar to the selectIntAddrMSA predicate from the Mips back end) return true instead of false. But

Le 07/03/2012 17:36, Jim Grosbach a écrit : > On Mar 7, 2012, at 6:23 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi Jim, >> >> Thanks for your response. >> >> Le 06/03/2012 22:54, Jim Grosbach a écrit : >>> Hi Ivan, >>> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >>>

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

In our architecture (TCE) we have predicate registers, not flags. But our predicates work in a way that in the predicated instruction do not contain only the predicate register, but a predicate register and boolean value pair, the boolean value stating if the instruction is to be executed only if the register is true(normal behavior of predicate regs) or only if the predicate reg is

On Oct 7, 2007, at 12:51 AM, Nikhil A. Patil wrote: > Hi, > > I am planning to generate code for a peculiar architecture with > _no_ branch instructions (!), but with predicated loads and stores > to memory. This means the architecture is not Turing complete, is > going to waste a lot of computation, and any input program that can > hope to get compiled for this