search for: typeleg

Probably, I misunderstood MemoryVT purpose? Should it be a type that equal to original vector type (e.g. v2i5). Or it is a type of memory area for this vector (e.g. v2i8) ? -Stepan. Stepan Dyatkovskiy wrote: > Hi all. The question about 'load' instruction. > When we promote > v2i5 = load<addr> ;<MemoryVT = v2i5> > to > v2i64 = load<addr> ;<MemoryVT

Hi Stepan, > Yes. It doesn't works properly. I also read the your discussion in bug 1784: > http://llvm.org/bugs/show_bug.cgi?id=1784 > I found that know Type and Vector Lagalization and in DAGCombining implicitly > assumed that element size of MemoryVT is multiply of 8 bits. Thats the main > reason why v2i5 works improperly with load/store. But I can't determine exactly

...adav [1] Intel's OpenCL SDK Vectorizer -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dan Gohman Sent: Tuesday, December 13, 2011 23:21 To: Stepan Dyatkovskiy Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [LLVM, llc] TypeLegalization, DAGCombining, vectors loading On Dec 13, 2011, at 11:37 AM, Stepan Dyatkovskiy wrote: > Please ignore my concurrent post :-) Lets proceed in this branch. > >> do you understand what it means in the non-vector case? > I'm beginning to understand it now. It means the t...

Hi all. The question about 'load' instruction. When we promote v2i5 = load <addr> ; <MemoryVT = v2i5> to v2i64 = load <addr> ;<MemoryVT = v2i5> should we insert vector shuffling that moves second v2i5 item to the second v2i64 item? Or it is still depends from target? Thanks. -Stepan.

On Dec 13, 2011, at 11:37 AM, Stepan Dyatkovskiy wrote: > Please ignore my concurrent post :-) Lets proceed in this branch. > >> do you understand what it means in the non-vector case? > I'm beginning to understand it now. It means the type that should be in > abstract VM memory. Isn't it? The main question about MemoryVT is: > should it be original always (as it

Yes. It doesn't works properly. I also read the your discussion in bug 1784: http://llvm.org/bugs/show_bug.cgi?id=1784 I found that know Type and Vector Lagalization and in DAGCombining implicitly assumed that element size of MemoryVT is multiply of 8 bits. Thats the main reason why v2i5 works improperly with load/store. But I can't determine exactly what MemoryVT means... -Stepan.

Please ignore my concurrent post :-) Lets proceed in this branch. > do you understand what it means in the non-vector case? I'm beginning to understand it now. It means the type that should be in abstract VM memory. Isn't it? The main question about MemoryVT is: should it be original always (as it was defined in .ll) or not? About vectors with element size less than 8 bits. This

...ill simplify things in a great sense is to make i16 legal (as it would make the pointer legal) and there onwards lower the types/operations ourselves to 8-bit (as type legalizer wouldn't do that). By doing that we would pretty much need to duplicate the legalizer code in our back-end as the TypeLegalizer interfaces currently are not exposed to TargetLowering. Or can a back-end just create an instance of Type Legalizer and use it? Thanks, - Sanjiv

...el will simplify things in a great sense is to make i16 legal (as it would make the pointer legal) and there onwards lower the types/operations ourselves to 8-bit (as type legalizer wouldn't do that). By doing that we would pretty much need to duplicate the legalizer code in our back-end as the TypeLegalizer interfaces currently are not exposed to TargetLowering. Or can a back-end just create an instance of Type Legalizer and use it? I don't have anything to suggest here. Dan

...1 = extractelement <2 x i1> %0, i32 %i.022 %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 %cmp6 = icmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0 t3: ch = ValueType:i32 t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1 t7: i32 = AssertZext t5, ValueType:ch:i1 t8: v2i32 = BUILD_VECTOR t2, t7 t11: v2i32 = BUILD_VECTOR Constant:...

...st in different register classes, and the operations that >> are legal on that type depend on the current register class. The reason >> this is a problem is that legalization happens before register-class >> assignment. > > Yes, that's correct. > >> Currently, isTypeLegal does not take an opcode parameter, but maybe >> changing it to depend on the type of operation (like getTypeToPromoteTo >> does) and the opcode of the node's inputs would help? > > I will try to see if I can fix isTypeLegal. > Thanks for your helpful comments. Just an id...

...gal:         return VT;       case Expand: Note that the values of different enum types (LegalizeAction and LegalizeTypeAction) are compared. This code works well because of the same order for enums, but it would be better to change this into       switch (getTypeAction(Context, VT)) {       case TypeLegal:         return VT;       case TypeExpand: ---- Thanks a lots for any fixes and answers.

...hen I use llc trunk or llc 3.1 it fails on an assert: llc: /work1/tools/llvm/trunk/sources/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:703: void<unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `TLI.getTypeAction(*DAG.getContext(), Node->getValueType(i)) == TargetLowering::TypeLegal && "Unexpected illegal type!"' failed. 0 libLLVM-3.2svn.so 0x00007fe073e4433f 1 libLLVM-3.2svn.so 0x00007fe073e4654a 2 libpthread.so.0 0x00007fe072d9d8f0 3 libc.so.6 0x00007fe07208ca75 gsignal + 53 4 libc.so.6 0x00007fe0720905c0 abort + 384 5 libc.so....

...rtunately, just adding the register class for MVT::i64 does not help either. In that case the code generation framework assumes that the TriCore could deal with MVT::i64 values and no longer expands all the MVT::i64-stuff to MVT::i32-stuff during type legalization. As the interface to configure the TypeLegalizeActions is not open to the particular target implementations, I just did a quick and dirty hack to tell the TypeLegalizer to expand operations on MVT::i64 values. Though, this triggers an assertion in "SelectionDAGLegalize::LegalizeOp". Before I am going to do more "unguided hac...

...y... - 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 about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT' Can someone give the comment about it please? Thanks, JinGu Kang On 14/09/17 12:05, jingu at codeplay.com wrote: > Hi All, > > I have a question about splitting 'EXTRACT_VECTOR_ELT' with 'v2i1'. I > have a llvm IR code snip...

Hi all, I'm currently working on an out-of-tree backend and am trying to improve the debug experience when debugging optimized code. Our backend only has 8-bit and 16-bit legal types, so any larger values are expanded. The behavior I am currently seeing is that the expanded halves of an illegal type lose their debug information. Is this the expected behavior? For example, if I have an

...use llc trunk or llc 3.1 it fails on an assert: > llc: /work1/tools/llvm/trunk/sources/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:703: void<unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `TLI.getTypeAction(*DAG.getContext(), Node->getValueType(i)) == TargetLowering::TypeLegal && "Unexpected illegal type!"' failed. > 0  libLLVM-3.2svn.so 0x00007fe073e4433f > 1  libLLVM-3.2svn.so 0x00007fe073e4654a > 2  libpthread.so.0   0x00007fe072d9d8f0 > 3  libc.so.6         0x00007fe07208ca75 gsignal + 53 > 4  libc.so.6         0x00007fe0720905c...

...Sent: Saturday, September 16, 2017 00:38 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com <daniel_l_sanders at apple.com>; Jon Chesterfield <jonathanchesterfield at gmail.com> 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...

...Expand: > > Note that the values of different enum types (LegalizeAction and > LegalizeTypeAction) are compared. This code works well because of the same order > for enums, but it would be better to change this into > > switch (getTypeAction(Context, VT)) { > case TypeLegal: > return VT; > case TypeExpand: Yup, I've made this change. > ---- > > Thanks a lots for any fixes and answers. Thanks for letting us know about these issues. Ciao, Duncan.

On Feb 10, 2010, at 8:57 AM, Sanjiv Gupta wrote: > Chris Lattner wrote: >> On Feb 9, 2010, at 7:39 PM, Sanjiv Gupta wrote: >> >> >>> Hi, >>> I need to add switches like -disable-mem2reg, disable-gvn to llvm-ld. >>> Currently CreateStandardLTOPasses takes in only DisableInternalize and >>> DisableInliner switches. >>>