search for: getscalartyp

The GEP constructor does not assert that the source and destination types match. Of course, this is incorrect and causes random failures somewhere down the line. Could I add general sanity checks to the GEP constructor? In general, is an Instruction allowed to be in an inconsistent state? If so, is there some well known method to "verify" whether an instruction is consistent or not?

...;PointerType&gt;(Ty); &nbsp; &nbsp; Type *vt = PointerTy-&gt;getElementType(); &nbsp; &nbsp; a = vt-&gt;isVectorTy(); &nbsp; } &nbsp; return a; } Then meet the following error: Assertion failed: ResultElementType == cast<PointerType&gt;(getType()-&gt;getScalarType())-&gt;getElementType(), file D:\cygwin64\home\celine\clang-102\llvm\include\llvm/IR/Instructions.h, line 958 I wonder how to create vector pointer type correctly? -- Best Regards, Celine -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm...

...t; Cc: llvm-dev at lists.llvm.org Subject: Re: Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT' Hi Elena, Thanks for your response. The store is ok but the extending load generates assertion after the store because MemVT is i8 and VT is i1 on following line. assert(MemVT.getScalarType().bitsLT(VT.getScalarType()) && "Should only be an extending load, not truncating!") so I think we need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. if (N->getOperand(0).getValueTyp...

> extends the elements to 8bit and stores them on stack. Store is responsible for zero-extend. This is the policy... - Elena -----Original Message----- From: jingu at codeplay.com [mailto:jingu at codeplay.com] Sent: Friday, September 15, 2017 17:45 To: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com Subject: Re: Question

...to:llvm-dev at lists.llvm.org> Subject: Re: Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT' Hi Elena, Thanks for your response. The store is ok but the extending load generates assertion after the store because MemVT is i8 and VT is i1 on following line. assert(MemVT.getScalarType().bitsLT(VT.getScalarType()) && "Should only be an extending load, not truncating!") so I think we need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. if (N->getOperand(0).getValueTyp...

...d treat a <scalable I x <J x <K x <L x ... type ...>>>> as a <scalable I x <(J * K * L * ...) x type>> for everything but result type. We could have methods on Type that return the next level down vector type, the scalar type under the vector type nest (probably getScalarType), and the number of total scalar elements (getVectorNumElementsRecursive) assuming VL is the first valid non-zero integer: so <scalable I x <J x <K x <L x ... type ...>>>> returns I * J * K * L * ... We will probably want to cache the innermost scalar type and the number of...

...larger than the byte size should be padded + // (e.g. i40 type for Phoenix is stored using 3 bytes (48 bits)). + bool PadElementsToByteSize = + isVector() && getScalarSizeInBits() >= BitsPerByte; + if (PadElementsToByteSize) + return getVectorNumElements() * getScalarType().getStoreSize(); + return (getSizeInBits() + (BitsPerByte-1)) / BitsPerByte; } The patch seems to work for in-tree-target tests as well as our out-of-tree target. If it is a correct assumption for all targets is beyond my knowledge. Maybe only i1 vectors should be bitpacked? Anyway, I...

...gt; +      // (e.g. i40 type for Phoenix is stored using 3 bytes (48 bits)). > > +      bool PadElementsToByteSize = > > +        isVector() && getScalarSizeInBits() >= BitsPerByte; > > +      if (PadElementsToByteSize) > > +        return getVectorNumElements() * getScalarType().getStoreSize(); > > +      return (getSizeInBits() + (BitsPerByte-1)) / BitsPerByte; > >      } > > The patch seems to work for in-tree-target tests as well as our > out-of-tree target. > > If it is a correct assumption for all targets is beyond my knowledge. > Ma...

...ply as-is. For safety, you could apply the one-line fix without > pulling the refactoring into the branch with this diff: > > - unsigned BitWidth = Q.DL.getTypeSizeInBits(TrueVal->getType()); > + unsigned BitWidth = > + Q.DL.getTypeSizeInBits(TrueVal->getType()->getScalarType()); > > > > > On Fri, Jul 22, 2016 at 7:45 AM, Hans Wennborg <hans at chromium.org> wrote: >> >> Sanjay: let me know if this is something that will apply to 3.9. >> >> Thanks, >> Hans >> >> On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel...

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

Got it. Thanks. I will try it with the trunk version. On Wed, Jan 20, 2016 at 1:36 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Zhi, > On 20 January 2016 at 13:33, zhi chen <zchenhn at gmail.com> wrote: > > Thanks for your response. The attached is the .bc file after my pass. I > > could generate the assembly with -mcpu=skx but not with

...y, you could apply the one-line fix without >> pulling the refactoring into the branch with this diff: >> >> - unsigned BitWidth = Q.DL.getTypeSizeInBits(TrueVal->getType()); >> + unsigned BitWidth = >> + Q.DL.getTypeSizeInBits(TrueVal->getType()->getScalarType()); >> >> >> >> >> On Fri, Jul 22, 2016 at 7:45 AM, Hans Wennborg <hans at chromium.org> wrote: >>> >>> Sanjay: let me know if this is something that will apply to 3.9. >>> >>> Thanks, >>> Hans >>> >>&g...

...e-line fix without > >> pulling the refactoring into the branch with this diff: > >> > >> - unsigned BitWidth = Q.DL.getTypeSizeInBits(TrueVal->getType()); > >> + unsigned BitWidth = > >> + Q.DL.getTypeSizeInBits(TrueVal->getType()->getScalarType()); > >> > >> > >> > >> > >> On Fri, Jul 22, 2016 at 7:45 AM, Hans Wennborg <hans at chromium.org > <javascript:;>> wrote: > >>> > >>> Sanjay: let me know if this is something that will apply to 3.9. > >>&...

When LLVM does a comparison of two vectors, in this case with 16 elements, the returned type of setcc is v16i1. The architecture I'm targeting allows storing the result of a vector comparison as a bit mask in a scalar register, but I'm having trouble converting the result of setcc into a value that is usable there. For example, if I try to AND together masks that are the results of two

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

...larger than the byte size should be padded + // (e.g. i40 type for Phoenix is stored using 3 bytes (48 bits)). + bool PadElementsToByteSize = + isVector() && getScalarSizeInBits() >= BitsPerByte; + if (PadElementsToByteSize) + return getVectorNumElements() * getScalarType().getStoreSize(); + return (getSizeInBits() + (BitsPerByte-1)) / BitsPerByte; } The patch seems to work for in-tree-target tests as well as our out-of-tree target. If it is a correct assumption for all targets is beyond my knowledge. Maybe only i1 vectors should be bitpacked? Anyway, I...

Jacob Lifshay <programmerjake at gmail.com> writes: > So it would be handy for the vector length on evl intrinsics to be in > units of the mask length so we don't have to pattern match a division > in the backend. We could have 2 variants of the vector length > argument, one in terms of the data vector and one in terms of the mask > vector. we could legalize the mask

...uld use '} else {'. Here braces are not needed at all. > + static inline VectorType *getVecType(Type *iType) { > + if (iType->isVectorTy()) { > + unsigned numElem = cast<VectorType>(iType)->getNumElements(); > + return VectorType::get(iType->getScalarType(), numElem*2); > + } > + else { > + return VectorType::get(iType, 2); > + } > + } > + > + // Note: when this function returns 0, the > + // resulting instructions are not actually fused. Use all 80 columns. What is a depth factor? Can you exp...

...;. Here braces are not needed at all. > > > + static inline VectorType *getVecType(Type *iType) { > > + if (iType->isVectorTy()) { > > + unsigned numElem = cast<VectorType>(iType)->getNumElements(); > > + return VectorType::get(iType->getScalarType(), numElem*2); > > + } > > + else { > > + return VectorType::get(iType, 2); > > + } > > + } > > + > > + // Note: when this function returns 0, the > > + // resulting instructions are not actually fused. > > Use a...

Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error in