search for: v16f16

I have been able to adapt the main LLVM sources to work with vectors of 16 x FP16 values and I have introduced the 'v16f16' data type to CLang and LLVM, but I am stumped on how to get TableGen to recognise this type. At the moment I am trying to optimise the calling convention code, and whenever I refer to 'v16f16' I get a crash in TableGen (unrecognised type). Unfortunately I haven't got my head aroun...

...nding the IR would be eliminated if we were a proper part of LLVM, which I would like to do when the time is right for us. My extensions are quite simple really, and I expect that they will be wanted in the TRUNK sometime anyway. At the moment I only have one remaining change which is to add 'v16f16' to the set of IR types. Previously I had several other FP16 vector types added, but over the past few iterations of LLVM my changes have been gradually made redundant because others have added them formally to the source. I expect that 'v16f16' will go this way too allowing me to hav...

Hi Sean, I had to add ‘v16f16’ to our out-of-tree target, and this was to primarily to allow me to express lowering for all the OpenCL types (well, except for the ‘v3T’ types). The trend does seem to be towards larger bit-width SIMD registers, and as you say this will increase in time; but perhaps instead of using a discret...

Hi, Our backend for Pixel Visual Core uses some MVT's that aren't upstream. Does it make sense to upstream them? I figure that as architectures get wider, we'll eventually have "all" possible combinations of widths and types, but on the other hand having code that isn't used by current backends in tree isn't great. These are the MVT's that we have added: 16x16

On Tue, Jan 16, 2018 at 11:13 PM, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Hi Sean, > > > > I had to add ‘v16f16’ to our out-of-tree target, and this was to > primarily to allow me to express lowering for all the OpenCL types (well, > except for the ‘v3T’ types). > > > > The trend does seem to be towards larger bit-width SIMD registers, and as > you say this will increase in time; but per...

Is there going to be a formal interface/API for this version-block information? I have had to "extend" the IR and bitcode representations several times to address absences/limitations in the handling of various vector types, in particular FP16 vector types; and it would be really useful if I had a "standard" way of doing this, and identifying that my dialect was different.