search for: isvectorized

[ Consumer warning: This is a little technical ... ] I have been pondering the question What should is.vector do? Martin has raised this a number of times. I ran a few tests in S and got the following results. S> is.vector(list(1,2,3)) [1] T S> is.vector(expression(a+b)) [1] T S> is.vector(as.name("x")) [1] T S> is.vector(NULL) [1] T S> x <- 1:5

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:

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

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

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

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

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... &nbsp;#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

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

Full_Name: Antonio Possolo Version: 1.3.1 OS: Linux (RH 7.1), Windows 2000 Submission from: (NULL) (192.35.44.3) A FEATURE THAT EASILY GENERATES BUGS sample(pi, size=1) produces 1, 2, or 3. sample(c(pi, pi), size=1) produces 3.141593 always. Although this conforms with the behavior explained in the help page for "sample", the behavior for the case where x (in sample(x, ...)) has

Hi all, I've run into a case where the optimizer seems to be having trouble doing the "obvious" thing. Consider this code: ``` define i16 @foo(<8 x i16>* dereferenceable(16) %egress, <16 x i8> %a0) { %a1 = icmp slt <16 x i8> %a0, zeroinitializer %a2 = bitcast <16 x i1> %a1 to i16 %astore = getelementptr inbounds <8 x i16>, <8 x i16>*

> > Line 4501 in trunk DAGCombiner.cpp… I changed the ISD::SELECT to the VT.isVector() ? ISD::VSELECT : ISD::SELECT... > Thanks. From the commit message I think that we should only run this optimization on scalars. >> Can you write down the input SDNode ? What types are inputs ? > > 0x107046d10: v2i8 = vselect 0x107046c10, 0x107046b10, 0x107045e10 [ID=-3]

This post is related to the following post http://lists.llvm.org/pipermail/llvm-dev/2016-April/098823.html I'm still trying to compile a library with clang. But now I'm getting as assert in lib/CodeGen/TargetLoweringBase.cpp:1155: virtual llvm::EVT llvm::TargetLoweringBase::getSetCCResultType(llvm::LLVMContext&, llvm::EVT) const: Assertion `!VT.isVector() && "No default

On Mar 8, 2013, at 2:29 PM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>> wrote: Hi Richard, visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… ISD::SELECT should be used for

In 2.8.0/Windows Vista: When 'unique' gives a type error message, it prints out even if errors are being caught: > try(unique(quote(hello)),silent=TRUE) hello This comes from the .Internal unique routine: > try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE) hello I guess it is using the internal equivalent of print rather than the internal equivalent of stop.

I'm working on version 2.0 The assertion at line 2380 of LegalizeDAG.cpp fails when it is trying to lower the add with i16. assertion reads: assert(MVT::isVector(Node->getValueType(0)) && "Cannot expand this binary operation!"); I am trying to compile a very simple program as follows: short var; void foo(void) { Var++; } The input bytecode, (in addition to the

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 optimization. If you send me the line number I will take a look. >> We should probably

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,

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