search for: typelegalizer

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

Dan, I completely agree with you. The vectorizer (or whoever generates this vector code) should be aware of the target instruction set and decide on the vectorization factor accordingly. When our vectorizer[1] decides on the vectorization factor, it takes into account the available instruction set, as well as the operations used in the program. For example, AVX1 focuses on floating point

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:i32&lt...

...of the node's inputs would help? > > I will try to see if I can fix isTypeLegal. > Thanks for your helpful comments. Just an idea, you may know that it's possible to custom expand operations with illegal types and it might be useful in this case (considering i1 as illegal). The TypeLegalizer will callback to your lowering function at the very beginning of the Combining/Legalization phases. If you add HexagonISD nodes in the process while promoting operands/result, you will be able to precisely match them later with its associated regclass (PReg?). Unfortunately, it will not resolve...

Hi. There are few one-line bugs Andrey Karpov have found with static analisys. He wrote a big article in russian on http://habrahabr.ru/blogs/compilers/125626/ for advertising purposes of static analyzer for Visual Studio his company developed. Most of the problems are easy to fix, so I list them in here for trunk version. Also few problems in clang code were found, I don't list them in here.

Hi all, considering following .ll file ; ModuleID = 'vect3x.ll' target triple = "armv7-none-linux-gnueabi" define arm_aapcscc void @test_hi_char8(i8* %.T0351, <8 x i8>* nocapture %srcA, <4 x i8>* nocapture %dst) noinline { L.entry: %0 = tail call arm_aapcscc i32 (...)* @get_global_id(i8* %.T0351, i32 0) %1 = bitcast <8 x i8>* %srcA to <4 x i8>*

...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 hacking and guessing", I want to task if there is an "official way" to support the setup described above, i.e. hav...

...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 snippet as...

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

Sounds like a bug in vector promote. If I restore this flag and use -promote-elements=0 everything works for me. Please fill a PR in LLVM bugzilla and assign to Nadav. On Mon, Jun 25, 2012 at 5:04 PM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi all, > > > considering following .ll file > > ; ModuleID = 'vect3x.ll' > target triple =

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

Hi Lockal S, > ---- > > lib/Target/X86/X86ISelLowering.cpp:11689 > !DAG.isKnownNeverZero(LHS)&& !DAG.isKnownNeverZero(LHS)) > > Note that there are identical subexpressions '!DAG.isKnownNeverZero (LHS)' to > the left and to the right of the '&&' operator. > The second subexpression should probably be !DAG.isKnownNeverZero(RHS)). a patch

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