search for: typelegalization

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

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

Dan Gohman wrote: > Have you ever investigated the following approach? Define fake > register+register forms of common instructions, in addition to the > register+memory forms. Let the instruction selector work as if > everything were in registers. Then, since there's only one physical > register, the register allocator will have to spill, and the spills > and reloads can

On Feb 10, 2010, at 9:17 PM, Sanjiv Gupta wrote: > Dan Gohman wrote: >> Have you ever investigated the following approach? Define fake >> register+register forms of common instructions, in addition to the >> register+memory forms. Let the instruction selector work as if >> everything were in registers. Then, since there's only one physical >> register, the

Hi All, I have a question about splitting 'EXTRACT_VECTOR_ELT' with 'v2i1'. I have a llvm IR code snippet as following: llvm IR code snippet: for.body: ; preds = %entry, %for.cond %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1>

On 25/05/2012 00:40, Sebastian Pop wrote: > On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov> wrote: >> Sebastian, >> >> First, it might be useful to look at what is done in the PowerPC >> backend. PPC also has condition registers that are larger than the >> 1-bit conditional results, and it defines 1-bit subregisters in >> addition to

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

Hi LLVM-Folks, at our department we have an in-house developed back-end for the TriCore processor and we want to upgrade it to LLVM 3.1. However, we have some troubles regarding some instructions that work on 64bit registers: The TriCore processor has 16 32bit registers that can be paired to form 64bit registers. Except a few instructions all work on 32bit registers, thus the TriCore processor

> 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

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 =

Please open a bugzilla ticket and attach your testcase. It will allow us to debug and fix the problem. Thanks - Elena From: JinGu [mailto:jingu at codeplay.com] 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

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