similar to: [LLVMdev] TableGen Type Contradiction

The AVX saga continues. I am attempting to write a pattern for VEXTRACTF128 but am having some problems. My attempt looks something like this: defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg, MRMDestMem, "extractf128", undef, X86f32, X86i32i8, // rr [(set VR128:$dst,

On Wed, Dec 2, 2009 at 3:46 PM, David Greene <dag at cray.com> wrote: > The AVX saga continues. > > I am attempting to write a pattern for VEXTRACTF128 but am having some > problems.  My attempt looks something like this: > > defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg, >                      MRMDestMem, "extractf128", undef,

On Aug 25, 2011, at 4:17 PM, Cameron McInally wrote: > Hey guys, > > Are spills/reloads of AVX registers using aligned stores/loads? Yes. > I can't > seem to find the code that aligns the stack slots to 32-bytes. Could > someone point me in the right direction? The register class has 256-bit spill alignment: def VR256 : RegisterClass<"X86", [v32i8, v16i16,

Hello, I am getting this error. What instruction is required to be implemented? LLVM ERROR: Cannot select: t22: v32i32 = vselect t724, t11, t16 t724: v32i32,ch = load<LD128[FixedStack1]> t723, FrameIndex:i64<1>, undef:i64 t659: i64 = FrameIndex<1> t10: i64 = undef t11: v32i32,ch = load<LD128[%sunkaddr45](align=4)(tbaa=<0x481f1e8>)> t0, t8, undef:i64

I have a few questions about the new vector shuffle matching code in the x86 .td files. It's a big improvement over the old system and provides the context that code generation for AVX needs. This is great! I'm asking because I'm having some trouble converting some AVX patterns over to the new system. I'm getting this error from tblgen: VyPERM2F128PDirrmi: (set:isVoid

On 08/31/2015 03:59 PM, Matthias Braun wrote: > Looks to me like the alignment is specified in tablegen. From Target.td: > > class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, > dag regList, RegAltNameIndex idx = NoRegAltName> > > X86RegisterInfo.td: > > def VR256 : RegisterClass<"X86", [v32i8,

David Greene <dag at cray.com> writes: > I'm asking because I'm having some trouble converting some AVX patterns > over to the new system. I'm getting this error from tblgen: > > VyPERM2F128PDirrmi: (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64 VR256:v4i64:$src1, (ld:v4i64

Hey guys, Are spills/reloads of AVX registers using aligned stores/loads? I can't seem to find the code that aligns the stack slots to 32-bytes. Could someone point me in the right direction? Thanks, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110825/b5724dec/attachment.html>

I'm having some trouble using bugpoint with newer version of gcc (bugpoint debug output below). I looked into the "conflicting type for malloc" problem and it doesn't seem easy to solve due to the unknown size of size_t (see LowerAllocations.cpp). The "void main()" problem is probably a result of this test being converted from Fortran. I'll have to dig into

Looking around today, it appears that TargetRegisterClass and MCRegisterClass only includes a single alignment. This is documented as being the minimum legal alignment, but it appears to often be greater than this in practice. For instance, on x86 the alignment of %ymm0 is listed as 32, not 1. Does anyone know why this is? Additionally, where are these alignments actually defined? I

I've run into an issue specifying intrinsics for AVX. Right now one can use GCCBuiltin to get automatic CBE (and other) support for emitting intrinsics as gcc builtins. It looks like this: def int_x86_sse3_hadd_pd : GCCBuiltin<"__builtin_ia32_haddpd">, Intrinsic<[llvm_v2f64_ty], [llvm_v2f64_ty, llvm_v2f64_ty], [IntrNoMem]>; AVX

Ah, thanks. That seems easy enough. Sorry to be pedantic, but does that snippet also handle cases where the frame pointer, %rbp, needs to be 32-byte aligned when dynamic allocas are present? I've looked at the ABI, but I don't see any guarantees about 32-byte frame alignment for AVX. That can be trouble when spill slots are based off of the frame pointer, not the stack pointer. Please

Che-Liang Chiou <clchiou at gmail.com> writes: > My purpose is to eliminate copy-paste style of programming in td files > as much as possible, but only to a point that the new language > constructs do not create too much overhead/readability-downgrade. Yes! > In other words, I am targeting those low-hanging fruit of copy-paste > programmings in td files that are eliminated

On Wednesday 16 July 2008 10:12, David Greene wrote: > I'm having some trouble using bugpoint with newer version of gcc (bugpoint > debug output below). I was using gcc 4.1.2. When I try 3.2.3 I get: bugpoint-test-program.bc.cbe.c:237: warning: conflicting types for built-in function `memcpy' bugpoint-test-program.bc.cbe.c: In function `main':

hello, i need to use v32i32 and v32f32 in store instructions. I defined my register as; def VRR128 : RegisterClass<"X86", [v32i32, v32f32], 1024, (add R_0_V_0, R_1_V_0, R_2_V_0)>; def STORE_DWORD : I<0x70, MRMDestMem, (outs), (ins i2048mem:$dst, VRR128:$src), "STORE_DWORD\t{$src, $dst|$dst, $src}",

Thank You. How to do the same for add please see the following; it gives duplication error. def VADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1, VRR128:$src2),"VADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRR128:$dst, (add VRR128:$src1, VRR128:$src2))]>, TA; def : Pat<(add VRR128:$src1, VRR128:$src2), (VADD VRPIM128:$src1, VRPIM128:$src2)>;

On Thu, Aug 5, 2010 at 3:11 PM, David A. Greene <greened at obbligato.org> wrote: > David Greene <dag at cray.com> writes: > >> I'm asking because I'm having some trouble converting some AVX patterns >> over to the new system.  I'm getting this error from tblgen: >> >> VyPERM2F128PDirrmi:   (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64

Hi, I have some newly defined intrinsic functions in my llvm IR code, which I want to translate to X86 instruction set. As a first step, I want to be able to generate "nop" for these instructions, so the program at least compiles successfully. The call to my intrinsic function looks like this in the IR: call void @llvm.X(i16 %43) >From what I understand it may be possible to

Thank You. But can we use same register class for fadd as well, is this instruction correct? def VFADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1, VRR128:$src2),"VFADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRR128:$dst, (fadd VRR128:$src1, VRR128:$src2))]>, TA; On Tue, Jul 11, 2017 at 9:00 PM, Craig Topper <craig.topper at gmail.com> wrote: >

Hi all, I started to write an LLVM backend for custom CPU. I created XXXInstrInfo but there are some problems. I searched for it but I couldn't find anything. Can anyone help me? include "XXXInstrFormats.td" def simm16 : Operand<i32> { let DecoderMethod = "DecodeSimm16"; } def mem : Operand<i32> { let PrintMethod = "printMemOperand"; let