search for: getsizeinbit

My experimental code calls DAG.getNode to construct a unary node with a flag result. Unfortunately the argument turns out to be constant, so lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2332 calls VT.getSizeInBits on the flag type, which isSimple(), so we call V.getSizeInBits at ValueTypes.h:560 and fail at ValueTypes.h:240: clang: .../include/llvm/CodeGen/ValueTypes.h:240: unsigned int llvm::MVT::getSizeInBits() const: Assertion `0 && "getSizeInBits called on extended MVT."' failed....

LLVMers, I have a const StructType *StTy where I call TargetData->getStructLayout(const_cast<StructType*>(StTy))->getSizeInBits() but it continues to return 64 regardless of the actual size of the struct? I want the size of the structure in bits, including alignment padding for offset calculations, is this not the right function call? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL:...

The LegalizeDAG.cpp file has this code in SelectionDAGLegalize::PromoteNode: case ISD::BSWAP: { unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, DAG.getConstant(DiffBits, TLI.getShiftAmountTy())); Results.push_back(Tmp1); break;...

Hello LLVM, In DAGCombiner.cpp, MergeConsecutiveStores uses int64_t ElementSizeBytes = MemVT.getSizeInBits()/8; https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L10669 which is broken for i1 types where getSizeInBits() == 1. My out-of-tree target hits this case and eventually LLVM asserts in Type.cpp. Is there some reason MergeConsecutiveStores should not exp...

...lt;3 x float>, returns the corresponding integer version of the vector. The problem comes in code like the following(comments removed): This is from DAGCombiner.cpp:visitSIGN_EXTEND. EVT N0VT = N0.getOperand(0).getValueType(); ... EVT SVT = TLI.getSetCCResultType(N0VT); ... if (VT.getSizeInBits() == SVT.getSizeInBits()) return DAG.getSetCC(N->getDebugLoc(), VT, N0.getOperand(0), N0.getOperand(1), cast<CondCodeSDNode>(N0.getOperand(2))->get()); SVT.getSizeInBits() crashes, because TLI.getSetCCResultType returns...

...lt;3 x float>, returns the corresponding integer version of the vector. The problem comes in code like the following(comments removed): This is from DAGCombiner.cpp:visitSIGN_EXTEND. EVT N0VT = N0.getOperand(0).getValueType(); ... EVT SVT = TLI.getSetCCResultType(N0VT); ... if (VT.getSizeInBits() == SVT.getSizeInBits()) return DAG.getSetCC(N->getDebugLoc(), VT, N0.getOperand(0), N0.getOperand(1), cast<CondCodeSDNode>(N0.getOperand(2))->get()); SVT.getSizeInBits() crashes, because TLI.getSetCCResultType returns...

...lt;3 x float>, returns the corresponding integer version of the vector. The problem comes in code like the following(comments removed): This is from DAGCombiner.cpp:visitSIGN_EXTEND. EVT N0VT = N0.getOperand(0).getValueType(); ... EVT SVT = TLI.getSetCCResultType(N0VT); ... if (VT.getSizeInBits() == SVT.getSizeInBits()) return DAG.getSetCC(N->getDebugLoc(), VT, N0.getOperand(0), N0.getOperand(1), cast<CondCodeSDNode>(N0.getOperand(2))->get()); SVT.getSizeInBits() crashes, because TLI.getSetCCResultType returns...

...n-linux-gnu/bin/ -c -DHAVE_CONFIG_H -g -O2 -I. -I/.../llvm/llvm-gcc-4.2/libiberty/../include  -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat /.../llvm/llvm-gcc-4.2/libiberty/fibheap.c -o fibheap.o cc1: .../llvm/llvm/include/llvm/CodeGen/ValueTypes.h:229: unsigned int llvm::MVT::getSizeInBits() const: Assertion `0 && "getSizeInBits called on extended MVT."' failed. Is anyone else getting this, or did I configure llvm-gcc to build incorrectly? This is what I specified: > mkdir build > cd build > $LLVMGCC/configure --prefix=`pwd`/../install --program-pref...

On Dec 22, 2009, at 2:38 PMPST, Bill Wendling wrote: > The LegalizeDAG.cpp file has this code in > SelectionDAGLegalize::PromoteNode: > > case ISD::BSWAP: { > unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); > Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); > Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); > Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, > DAG.getConstant(DiffBits, > TLI.getShiftAmountTy())); > Results.pus...

I was going through the function DAGTypeLegalizer::SplitVecRes_LOAD in LegalizeVectorTypes.cpp. I noticed that it is using getSizeInBits()/8 to compute IncrementSize, which is the offset for the load of second half of the vector. I have a situation where the frontend is producing load for a <2 x i1> type, and the architecture has i1 registers (but not v2i1 registers). The store size of i1 is 8 bits (the size returned by getSt...

...lt;3 x float>, returns the corresponding integer version of the vector. The problem comes in code like the following(comments removed): This is from DAGCombiner.cpp:visitSIGN_EXTEND. EVT N0VT = N0.getOperand(0).getValueType(); ... EVT SVT = TLI.getSetCCResultType(N0VT); ... if (VT.getSizeInBits() == SVT.getSizeInBits()) return DAG.getSetCC(N->getDebugLoc(), VT, N0.getOperand(0), N0.getOperand(1), cast<CondCodeSDNode>(N0.getOperand(2))->get()); SVT.getSizeInBits() crashes, because TLI.getSetCCResultType returns...

...SelectionDAG/DAGCombiner.cpp (revision 191902) +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp (working copy) @@ -3415,12 +3415,16 @@ // (*ext (rotr x, (sub 32, y))) SDValue LArgExtOp0 = LHSShiftArg.getOperand(0); EVT LArgVT = LArgExtOp0.getValueType(); - if (LArgVT.getSizeInBits() == SUBC->getAPIntValue()) { - SDValue V = - DAG.getNode(HasROTL ? ISD::ROTL : ISD::ROTR, DL, LArgVT, - LArgExtOp0, HasROTL ? LHSShiftAmt : RHSShiftAmt); - return DAG.getNode(LHSShiftArg.getOpcode(), DL, VT, V).getNode(); - } +...

...::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always false due to limited range of data type And on "make check" would print out: llc: /scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:231: unsigned int llvm::MVT::getSizeInBits() const: Assertion `0 && "getSizeInBits called on extended MVT."' failed. 0 llc 0x0000000000ee2bef 1 llc 0x0000000000ee488d 2 libpthread.so.0 0x00007f988a8f8e90 3 libc.so.6 0x00007f9889c022f5 gsignal + 53 4 libc.so.6 0x00007f9889c...

...onLegalOrCustom(ISD::ADD, VT) && TLI.isOperationLegalOrCustom(ISD::XOR, VT) && "Don't know how to expand this subtraction!"); Tmp1 = DAG.getNode(ISD::XOR, dl, VT, Node->getOperand(1), DAG.getConstant(APInt::getAllOnesValue(VT.getSizeInBits()), VT)); Tmp1 = DAG.getNode(ISD::ADD, dl, VT, Tmp2, DAG.getConstant(1, VT)); Results.push_back(DAG.getNode(ISD::ADD, dl, VT, Node->getOperand(0), Tmp1)); break; } The problem is Tmp2 is not initialized and should be Tmp1 instead. This code only is hit if the architecture does n...

...1 = getelementptr inbounds %"atomic::AtomicI16", %"atomic::AtomicI16"* %0, i16 0, i32 0, i32 0 %2 = load atomic i16, i16* %1 seq_cst, align 1 ret void } This trips up the following assertion in CodeGen/SelectionDAG/SelectionDAGBuilder.cpp: if (I.getAlignment() < VT.getSizeInBits() / 8) report_fatal_error("Cannot generate unaligned atomic load"); I've tried commenting out the check and llc finishes, generating not-obviously-wrong machine code, so there doesn't seem to be anything further downstream breaking because of this. So my questions are:...

...ethod 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 { - return (getSizeInBits() + 7) / 8; + // We assume that vectors with elements smaller than the byte size are + // bitpacked. And that elements larger than the byte size should be padded + // (e.g. i40 type for Phoenix is stored using 3 bytes (48 bits)). + bool PadElementsToByteSize = + isVector...

...t 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 { > > -      return (getSizeInBits() + 7) / 8; > > +      // We assume that vectors with elements smaller than the byte > size are > > +      // bitpacked. And that elements larger than the byte size > should be padded > > +      // (e.g. i40 type for Phoenix is stored using 3 bytes (48 bits)). > > +...

On Nov 10, 2008, at 1:20 PM, Daniel M Gessel wrote: > I've been running into two issues with load/store handling: > > (1) is that tablegen doesn't seem to handle the two predicates that > get attached to my instructions. The first is the predicate in > TargetSelectionDAG.td, identifying a load node as, say, extloadi8. The > second is my identification of the load as

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> 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