similar to: [LLVMdev] [PATCH] Add custom UINT_TO_FP lowering from v2i32 to v2f32 in 32-bit mode

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and

Hi Hal, On 05/03/13 18:50, Hal Finkel wrote: > Hello, > > Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: > > Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] > > Scalarize node result 0: 0x2348220: v1f32 = extract_subvector

Digging deeper... 1. Is there a good reason that v2f32 types are excluded from the isFloatingPoint filter? Looks like a bug to me. v2f32 = 22, // 2 x f32 v4f32 = 23, // 4 x f32 <== start ?? v2f64 = 24, // 2 x f64 <== end static inline bool isFloatingPoint(ValueType VT) { return (VT >= f32 && VT <= f128) || (VT

Hello, Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] Scalarize node result 0: 0x2348220: v1f32 = extract_subvector 0x23434a0, 0x23466e0 [ID=0] Split node result: 0x23469e0: v4f32 =

Hi, I'm implementing the built_vector as an IMPLICIT_DEF followed by INSERT_SUBREGs. This approach is the one of the SPARC architecture. def : Pat<(build_vector (f32 fpimm:$a1), (f32 fpimm:$a2)), (INSERT_SUBREG(INSERT_SUBREG (v2f32 (IMPLICIT_DEF)), (i32 (COPY_TO_REGCLASS (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 f32:$a1)), FPUaOffsetClass)), A_UNIT_PART),

If I force it to use v2f32 for my register class, it still fails with: d:\hq\main\sw\appeng\tools\hpc\opencl\compiler\llvm\test\AMDIL>TableGen. exe -gen -dag-isel -I../../include/ test.td > output GPRV2F32:v2f32:$src1 MACRO_DISTANCE_FAST_v2f32: (set GPRF32:f32:$dst, (i ntrinsic_w_chain:f32 84:iPTR, GPRV2F32:v2f32:$src0, GPRV2F32:v2f32:$src1)) TableGen.exe: In

Hello everybody, I'm reading the .td files defining the Cortex-A57 processor, which is a subtarget of AArch64 target, and there is something confusing me in the `AArch64SchedA57.td` file. In the top of `AArch64SchedA57.td`, various processor resource are defined, as follows ``` def A57UnitB : ProcResource<1>; // Type B micro-ops def A57UnitI : ProcResource<2>; // Type

On Apr 15, 2009, at 1:11 PM, Villmow, Micah wrote: > If I force it to use v2f32 for my register class, it still fails with: > d:\hq\main\sw\appeng\tools\hpc\opencl\compiler\llvm\test > \AMDIL>TableGen. > exe -gen > -dag-isel -I../../include/ test.td > output > GPRV2F32:v2f32:$src1 MACRO_DISTANCE_FAST_v2f32: (set > GPRF32:f32:$dst, (i > ntrinsic_w_chain:f32

Hi, I'm trying to optimize the 'extract_vector_elt' for my SIMD microcontroller. The idea is, during DAG combination, to merge load/extract sequence into an architecture specific node. During Instruction Selection, this specific node will be target selected to an architecture specific instruction. By 'combination of DAG nodes' I understand 'replacing a set of DAG nodes by

Hi, On 01/22/2016 05:02 PM, Tom Stellard wrote: > On Fri, Jan 22, 2016 at 01:58:49PM +0100, Mikael Holmén via llvm-dev wrote: >> Hi, >> >> I'm a litle bit puzzled by the TargetLowering::LowerOperation function, >> and what different callers of this function assumes about the returned >> value. >> > SelectionDAGLegalize::LegalizeOp() is your best

Hello, I am trying to convert the subtree (vector_shuffle v2f32, v2f32 (build_vector imm1, imm2)) to a machine instruction that takes 2 v2f32's and 2 immediates. I tried the following table gen pattern : (set v2f32Reg:$dst, (vector_shuffle v2f32Reg:$src1, v2f32Reg:$src2, (build_vector imm:$c1, imm:$c2))) Table gen barfs about type

On Apr 15, 2009, at 11:15 AM, Villmow, Micah wrote: > I still think there is a bug somewhere, but not sure where yet. > This is what is generated in intrinsic.gen: > case Intrinsic::opencl_math_fdistance: // > llvm.opencl.math.fdistance > ResultTy = Type::FloatTy; > ArgTys.push_back(Tys[0]); > ArgTys.push_back(Tys[0]); > break; OK. That looks right to me.

Hi; i am using llvm backend on x86 arch. My app ABI requires float2 (v2f32) to be passes as parameter and return in XMM0 register. Currently LLVM handles v2f32 using MMX register MM0. i wonder what changes do i need to do in LLVM to support that change; manipulating v2f32 (float2) using XMM and not MMX ? one place i identifies where a change needs to be done is X86CallingConv.td where it

The X86-64 calling convention (annoyingly) specifies that "struct x { float a,b,c,d; }" is passed or returned in the low 2 elements of two separate XMM registers. For example, returning that would return "a,b" in the low elements of XMM0 and "c,d" in the low elements of XMM1. Both llvm-gcc and clang currently generate atrocious IR for these structs, which you can

On Sun, 22 Apr 2007, Christopher Lamb wrote: > 1. Is there a good reason that v2f32 types are excluded from the > isFloatingPoint filter? Looks like a bug to me. > > v2f32 = 22, // 2 x f32 > v4f32 = 23, // 4 x f32 <== start ?? > v2f64 = 24, // 2 x f64 <== end > > static inline bool isFloatingPoint(ValueType VT) {

On Apr 23, 2007, at 5:08 PM, Chris Lattner wrote: > On Sun, 22 Apr 2007, Christopher Lamb wrote: >> 1. Is there a good reason that v2f32 types are excluded from the >> isFloatingPoint filter? Looks like a bug to me. >> >> v2f32 = 22, // 2 x f32 >> v4f32 = 23, // 4 x f32 <== start ?? >> v2f64 = 24, // 2 x

On 2011-03-09 02:51, Bill Wendling wrote: > There are LLVM 2.9 RC1 pre-release tarballs source available. You can find them here: > llvm 2.9rc1 test on Dualcore ARM running Ubuntu Natty gunzip llvm-2.9rc1.src.tar.gz tar zxvf llvm-2.9rc1.src.tar cd llvm-2.9-build ../llvm-2.9rc1/configure --enable-shared time make clean ;time make CXXFLAGS=-marm CFLAGS=-marm xranby at

On Wed, Apr 15, 2009 at 11:15 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I still think there is a bug somewhere, but not sure where yet. > This is what is generated in intrinsic.gen: > case Intrinsic::opencl_math_fdistance:          // > llvm.opencl.math.fdistance >    ResultTy = Type::FloatTy; >    ArgTys.push_back(Tys[0]); >    ArgTys.push_back(Tys[0]);

I have a back end which has both scalar and vector registers that alias each other. I'm having a problem generating the ISel from tablegen that appears only when a vector register class is declared to contain integer vectors. At that moment tablegen doesn't seem to be able to infer integer types in patterns that it was able to before, but I'm not clear on why that's the

I am trying to upgrade to the LLVM v4.0 branch, but I am seeing failures in my TableGen descriptions for conversion from FP32 to FP16 (scalar and vector). The patterns I have are along the lines of: [(set (f16 RF16:$dst), (fround (f32 RF32:$src)))] or: [(set (v2f16 VF16:$dst), (fround (v2f32 VF32:$src)))] and these now produce the errors: error: In CONV_f32_f16: Type inference