similar to: R-alpha: What should is.vector do?

Hi, The full trace stack: Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824! [ 85%] Building X86GenEVEX2VEXTables.inc...  #0 0x000000000081b9b5

Here's a reworked patch to mark instructions and operands as vector or scalar. It uses TableGen to infer the flags from types, allowing the user to override with a "let isVector = 0" clause. I decided to forego classifying MachineMemOperands for now in the interests of getting this piece in. I still think we should add type information to MachineMemOperands. Why throw away

def STOREbos { // InstructionEncoding Instruction RPPInst RPPInstMMEMrr &nbsp; field bits<32&gt; Inst = { 0, 0, 0, 1, rs1{2}, rs1{1}, rs1{0}, index{0}, 0, 0, 0, 1, 0, rbase{3}, rbase{2}, rbase{1}, rbase{0}, rbase{4}, roffset{4}, roffset{3}, roffset{2}, roffset{1}, roffset{0}, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; &nbsp; field bits<32&gt; SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

Hi Krzysztof, Today I try it on llvm9.0.0 version. &nbsp; def bos : RPPInstMMEMrr<OPC_STORE, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (outs), (ins MGPR:$rs1, SGPR32:$rbase, MGPR:$roffset, uimm2:$rshift), &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; !strconcat(opcodestr, ""), "$rs1,

You are welcome. I changed the pattern, the same old error pop up again, crash in the same place. Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: &nbsp; (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!

On Friday 04 December 2009 16:44, David Greene wrote: > Here's a reworked patch to mark instructions and operands as vector or > scalar. It uses TableGen to infer the flags from types, allowing the user > to override with a "let isVector = 0" clause. > > I decided to forego classifying MachineMemOperands for now in the interests > of getting this piece in. I still

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > We're in-progress designing a RISC-V extension (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) that would have variable-length vectors of short vectors (1 to 4): > <VL x <4 x

We should handle this a lot better after r34763 ~Craig On Mon, Nov 26, 2018 at 3:13 PM Craig Topper <craig.topper at gmail.com> wrote: > Here's a quick patch that fixes this. I don't know to avoid it in IR. I > haven't checked any other tests, but it does fix your case. I'll try to put > up a real phabricator tonight or tomorrow. > > diff --git

On Dec 9, 2009, at 8:20 AM, David Greene wrote: > On Tuesday 08 December 2009 16:01, Dan Gohman wrote: > >>> I don't see how a register MachineOperand is obviously a vector unless >>> there's type information somewhere that I'm missing. >> >> It has a register which has a register class. It's true that LLVM >> currently uses one register

Hello, I'm trying to fetch a data frame through the C API, and have no problem doing this when all columns are numbers, but when there is a column of strings I have a problem. On the C-side the function looks like: SEXP myfunc(SEXP df), and it is called with a dataframe from the R side with: .Call("myfunc", somedataframe) On the C side (actually C++ side) I use code like this:

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

What is the proper solution to disable auto-vectorization for unaligned data? I have an out of tree target and I added this: bool OpusTargetLowering::allowsUnalignedMemoryAccesses(EVT VT, bool *Fast) const { if (VT.isVector()) return false; .... } After that, I could see that vectorization is still done on unaligned data except that llvm will copy the data back and forth from the source

On Feb 12, 2007, at 12:58 PM, Evan Cheng wrote: > > On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > >> >> selector refused to select certain ops (specifically stores) for some >> instructions when the operand type wasn't the first type for the >> register class. After some digging around I seem to have solved the >> problem by creating bitconvert

Consider the R code: mat <- matrix(seq(1,20),4,5) is.matrix(mat) # gives TRUE is.vector(mat) # gives FALSE On the other hand, if mat is passed through the .Call interface the corresponding SEXP (call it smat) satisfies isMatrix(smat) // TRUE isVector(smat) // TRUE Consequently, you cannot distinguish matrices from vectors. Looking at the dim attribute of a vector doesn't help because

> > Thanks Evan, > > I had tried something like this, but ran into some problems. > > llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1478: failed assertion > `MVT::isVector(VT) && "Cannot promote this load!"' > > and > > llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1766: failed assertion > `MVT::isVector(VT) && "Unknown legal

On Mar 11, 2013, at 9:41 AM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>> wrote: Hi Richard, I did… It originates from an icmp ne <2x i8>, zero initializer followed by a sext of the result 2x i1 to 2x i8. When we visit the SIGN_EXTEND, we generate the ISD::SELECT even though the selector and both operands are vectors. It sounds like a bug in the dag combine

Hi, > On 6 Jun 2018, at 17:36, David A. Greene <dag at cray.com> wrote: > > Graham Hunter via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> Ok, now I understand what you're getting at. A ConstantExpr would >>> encapsulate this computation. We alreay have "non-static-constant" >>> values for ConstantExpr like sizeof and

Hi Robin, responses inline. -Graham > On 11 Jun 2018, at 16:47, Robin Kruppe <robin.kruppe at gmail.com> wrote: > > Hi Graham, > Hi David, > > glad to hear other people are thinking about RVV codegen! > > On 7 June 2018 at 18:10, Graham Hunter <Graham.Hunter at arm.com> wrote: >> >> Hi, >> >>> On 6 Jun 2018, at 17:36, David A.

Hi David, >>> The name "getSizeExpressionInBits" makes me think that a Value >>> expression will be returned (something like a ConstantExpr that uses >>> vscale). I would be surprised to get a pair of integers back. Do >>> clients actually need constant integer values or would a ConstantExpr >>> sufffice? We could add a ConstantVScale or

On Tue, 31 Jul 2018 at 03:53, David A. Greene <dag at cray.com> wrote: > I wasn't talking about within an instruction but rather across > instructions in the same expression tree. Something like this would be > weird: Yes, that's what I was referring as "not in the API" therefore "user error". > The points where VL would be changed are limited and