search for: getstoresize

...f > those (v2i40, v4i40). > > And the byte size in our target is 16 bits. > > When storing an i40 we need to store it as three 16-bit bytes, i.e. 48 > bits. > > When storing a v4i40 vector it will be stored as 4x48 bits. > > One thing that we have had to patch is the getStoreSize() method in > ValueTypes/MachineValueTypes where we assume that vectors are > bitpacked when the element size is smaller than the byte size > (“BitsPerByte”): > >      /// Return the number of bytes overwritten by a store of the > specified value > >      /// type. >...

...the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our target is 16 bits. When storing an i40 we need to store it as three 16-bit bytes, i.e. 48 bits. When storing a v4i40 vector it will be stored as 4x48 bits. One thing that we have had to patch is the getStoreSize() method in ValueTypes/MachineValueTypes where we assume that vectors are bitpacked when the element size is smaller than the byte size (“BitsPerByte”): /// Return the number of bytes overwritten by a store of the specified value /// type. unsigned getStoreSize() const { - retu...

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

...to bit pack vectors, should we do it for any element size, or only when element size is less than the byte size, or only for i1 vectors? Maybe bit packing should be optional (target specific)? Btw, the IR/ISD note for a <2 x i2> store indicates that it is an one byte (ST1) store, due to the getStoreSize() methods saying one byte for this kind of vector. So alias analysis etc thinks that only one byte is written. ________________________________________ From: Friedman, Eli <efriedma at codeaurora.org> Sent: Monday, September 25, 2017 8:08:01 PM To: Björn Pettersson A; Jon Chesterfield Cc: llv...

...ere, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop] jddupas% clang -arch i386 -c round.c Assertion failed: (memvt.getStoreSize() == MMO->getSize() && "Size mismatch!"), function MemSDNode, file /Volumes/MacPro/Projects/OpenSource/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp, line 5393. 0 clang 0x0000000100df5422 PrintStackTrace(void*) + 34 1 clang 0x0000000100df5999 SignalHa...

...; > Trying to compile the following simple code, clang asserts. > > ---------- round.c -------- > #include <math.h> > float test() { return llround(1); } > -------------------- > > [MacPro:~/Desktop] jddupas% clang -arch i386 -c round.c > Assertion failed: (memvt.getStoreSize() == MMO->getSize() && "Size mismatch!"), function MemSDNode, file /Volumes/MacPro/Projects/OpenSource/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp, line 5393. > 0 clang 0x0000000100df5422 PrintStackTrace(void*) + 34 > 1 clang 0x0000000100df599...

...PT deciding to opt to a type that is not allowed, No, I think the SelectionDAG legalization should be able to "undo" any illegal type as well. For loads/stores, this usually means making the memory size bigger. For instance, an i4 store would be legalized to use i8, and that's what getStoreSize is for. LLVM assumes 8bit byte-addressing though, so that's fine. Again, you can't really change the number of bytes addressed though, so you can't do much here. > but that's > the design choice made by LLVM: to allow illegal operations AND types during > the pre-legaliz...

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from the fact I actually did NOT have defined type v128i64 in files: [repo]/llvm/include/llvm/IR/Intrinsics.td [repo]/llvm/include/llvm/CodeGen...

..., t130, t193, TargetConstant:i64<0>, t121 llc: /home/asusu/LLVM/llvm38Nov2016/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:6804: llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed. Does anybody know why this happens? I'd like to mention that I also gave in [Target]ISelLowering.cpp a call to setOperationAction(ISD::MGATHER, aType, Legal), which should have fixed this problem, but it doesn...

...;MRI = MF->getRegInfo(); + MachineInstrBuilder MIB; + + // Memory Reference + MachineInstr::mmo_iterator MMOBegin = MI->memoperands_begin(); + MachineInstr::mmo_iterator MMOEnd = MI->memoperands_end(); + + MVT PVT = getPointerTy(MF->getDataLayout()); + unsigned PtrSize = PVT.getStoreSize(); + assert(PVT == MVT::i32 && "Invalid Pointer Size!"); + + unsigned Buf = MI->getOperand(0).getReg(); + unsigned JmpLoc = MRI.createVirtualRegister(&SP::IntRegsRegClass); + + // Instruction to load jmp location + MIB = BuildMI(*MBB, MI, DL, TII->get(SP::LDri)...

Hi, I'm trying to implement __builtin_setjmp / __builtin_longjmp for Sparc processors. I think I'm very close, but I can't work out how to issue BuildMI-type instructions to load the address of the recovery location (set in setjmp) into a register using the SETHI / OR combination. I can't see any equivalent code anywhere else in Sparc. I imagine this is similar if I try to make a

On Wed, Mar 4, 2015 at 10:49 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> Yes, it is breaking during the legalize phase, depending on which >> TargetLowering callback method we use. For example, Custom will let it >> through to instructions selection, which it breaks at the

Hello. Will, thanks a lot for pointing me to the MaskedGatherSDNode and mgatherv4i32. I have to say that the definition of the "multiclass avx512_gather" from lib/Target/X86/X86InstrAVX512.td is difficult to follow and I prefer not to use it. I currently have some serious problems with TableGen - it gives an assertion failure:

...SynchronizationScope SynchScope) { if (Alignment == 0) // Ensure that codegen never sees alignment 0 Alignment = getEVTAlignment(MemVT); @@ -4278,15 +4290,16 @@ SDValue SelectionDAG::getAtomic(unsigned Opcode, SDLoc dl, EVT MemVT, MF.getMachineMemOperand(PtrInfo, Flags, MemVT.getStoreSize(), Alignment); return getAtomic(Opcode, dl, MemVT, Chain, Ptr, Cmp, Swp, MMO, - Ordering, SynchScope); + SuccessOrdering, FailureOrdering, SynchScope); } SDValue SelectionDAG::getAtomic(unsigned Opcode, SDLoc dl, EVT MemVT, -...