search for: couperus

...I migrated AVR target for lld https://reviews.llvm.org/D32991 it is very beginning, only support R_AVR_CALL reloc, and ARC is more complex than AVR, I will learn it from binutils, also ARC related doc, then try to implement it. 发自我的iPhone ------------------ Original ------------------ From: Pete Couperus <Peter.J.Couperus at synopsys.com> Date: 周五,9月 1,2017 11:17 下午 To: Leslie Zhai <lesliezhai at llvm.org.cn>, Peter.J.Couperus at synopsys.com <Peter.J.Couperus at synopsys.com> Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: RE: [RFC] Adding ARC backe...

...look is in instruction selection for loads and stores to the VFP/NEON registers. That code can be made smarter to better use the NEON instructions. I know Jakob has done some work related to better utilization of those for other constructs. > > -Jim > > On Sep 5, 2012, at 4:25 PM, Peter Couperus<peter.couperus at st.com> wrote: > >> Hello Jim, >> >> Thank you for the response. I may be confused about the alignment rules here. >> I had been looking at the ARM RVCT Assembler Guide, which seems to indicate vld1.16 operates on 16-bit aligned data, unless I am...

...ned address unless the target explicitly days that unaligned loads are OK. > > For your situation, either the subtarget should set AllowsUnalignedMem to true (if that's accurate), or the load address should be made 64-bit aligned. > > -Jim > > On Sep 5, 2012, at 2:42 PM, Peter Couperus<peter.couperus at st.com> wrote: > >> Hello all, >> >> I am a first time writer here, but am a happy LLVM tinkerer. It is a pleasure to use :). >> We have come across some sub-optimal behavior when LLVM lowers loads for vectors with small integers, i.e. load<4...

...le to upstream. > > -Dave > > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Peter Couperus > Sent: Thursday, September 06, 2012 8:14 AM > To: Jim Grosbach > Cc: Jakob Olesen; llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu) > Subject: Re: [LLVMdev] Unaligned vector memory access for ARM/NEON. > > Hello, > > Thanks again. We did try overestimating the alignment,...

...e proper place to look is in instruction selection for loads and stores to the VFP/NEON registers. That code can be made smarter to better use the NEON instructions. I know Jakob has done some work related to better utilization of those for other constructs. -Jim On Sep 5, 2012, at 4:25 PM, Peter Couperus <peter.couperus at st.com> wrote: > Hello Jim, > > Thank you for the response. I may be confused about the alignment rules here. > I had been looking at the ARM RVCT Assembler Guide, which seems to indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting th...

...have some code to do this that I will likely be able to upstream. -Dave -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Peter Couperus Sent: Thursday, September 06, 2012 8:14 AM To: Jim Grosbach Cc: Jakob Olesen; llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu) Subject: Re: [LLVMdev] Unaligned vector memory access for ARM/NEON. Hello, Thanks again. We did try overestimating the alignment, and saw the vldr you reference here. It...

Hello, We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from the ARM backend. Would there be any potential harm by marking VSELECT as Expand on ARM targets with NEON? Adding this seems to fix the following PR's: http://llvm.org/bugs/show_bug.cgi?id=13831 http://llvm.org/bugs/show_bug.cgi?id=13961 Thanks! Pete

Seems reasonable to me. Plain 'SELECT' is already marked expand for vector types. I bet that just didn't get updates when VSELECT was introduced. -Jim On Oct 11, 2012, at 10:25 AM, Peter Couperus <peter.couperus at st.com> wrote: > Hello, > > We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from the ARM backend. > Would there be any potential harm by marking VSELECT as Expand on ARM targets with NEON?...

...11, 2012, at 11:05 AM, Jim Grosbach <grosbach at apple.com> wrote: > Seems reasonable to me. Plain 'SELECT' is already marked expand for vector types. I bet that just didn't get updates when VSELECT was introduced. > > -Jim > > On Oct 11, 2012, at 10:25 AM, Peter Couperus <peter.couperus at st.com> wrote: > >> Hello, >> >> We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from the ARM backend. >> Would there be any potential harm by marking VSELECT as Expand on AR...

-----Original Message----- From: Bob Wilson [mailto:bob.wilson at apple.com] Sent: Thursday, September 06, 2012 3:39 PM To: David Peixotto Cc: 'Peter Couperus'; 'Jim Grosbach'; 'Jakob Olesen'; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Unaligned vector memory access for ARM/NEON. On Sep 6, 2012, at 2:48 PM, David Peixotto <dpeixott at codeaurora.org> wrote: > Hi Pete, > > We ran into the same issue with generatin...

On Sep 6, 2012, at 4:40 PM, David Peixotto <dpeixott at codeaurora.org> wrote: > -----Original Message----- > From: Bob Wilson [mailto:bob.wilson at apple.com] > Sent: Thursday, September 06, 2012 3:39 PM > To: David Peixotto > Cc: 'Peter Couperus'; 'Jim Grosbach'; 'Jakob Olesen'; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Unaligned vector memory access for ARM/NEON. > > > On Sep 6, 2012, at 2:48 PM, David Peixotto <dpeixott at codeaurora.org> wrote: > >> Hi Pete, >> >> We r...

Hi Pete, > https://reviews.llvm.org/D36331 Congratulations! > Following shortly: > * Clang driver and target triple support. great, then it is able to generate ELF by $ /opt/llvm-svn/bin/clang -c --target=arc hello.c -o hello.o -mmcu=XXX and do you plan to implement ARC target for lld[1]? it is a good testcase: flash them directly to the chip[2], or simulator[3]. 1. ARC

VLD1 expects a 64-bit aligned address unless the target explicitly days that unaligned loads are OK. For your situation, either the subtarget should set AllowsUnalignedMem to true (if that's accurate), or the load address should be made 64-bit aligned. -Jim On Sep 5, 2012, at 2:42 PM, Peter Couperus <peter.couperus at st.com> wrote: > Hello all, > > I am a first time writer here, but am a happy LLVM tinkerer. It is a pleasure to use :). > We have come across some sub-optimal behavior when LLVM lowers loads for vectors with small integers, i.e. load <4 x i16>* %a, ali...

> -----Original Message----- > From: Bob Wilson [mailto:bob.wilson at apple.com] > Sent: Friday, September 07, 2012 10:57 AM > To: David Peixotto > Cc: 'Peter Couperus'; 'Jim Grosbach'; 'Jakob Olesen'; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Unaligned vector memory access for ARM/NEON. > > > On Sep 6, 2012, at 4:40 PM, David Peixotto <dpeixott at codeaurora.org> > wrote: > > > -----Original Message-----...

Hello all, I am a first time writer here, but am a happy LLVM tinkerer. It is a pleasure to use :). We have come across some sub-optimal behavior when LLVM lowers loads for vectors with small integers, i.e. load <4 x i16>* %a, align 2, using a sequence of scalar loads rather than a single vld1 on armv7 linux with NEON. Looking at the code in svn, it appears the ARM backend is capable of

On Mon, Apr 22, 2013 at 8:09 AM, Pete Couperus <pjcoup at gmail.com> wrote: > Hello Reed, > > Basic blocks need to end with a terminator instruction. > There is an "unreachable" terminator instruction, whose documentation says: > "the presence of this instruction indicates some higher level knowledge > th...

On 05/30/2013 06:12 AM, Pete Couperus wrote: > Hello, > > This is an interesting example. Whenever I see strange things like > this, I use opt's -lint. > In this case, opt -lint reports: > Undefined behavior: Call return type mismatches callee return type > %call = call float @alias_f32(float %tmp2) #1 >...

Hello, Context: We have a backend where v32i1 is a Legal type, but the storage for v32i1 is not 32-bits/uses a different instruction sequence. We ran into an issue because combineLoadToOperationType changed v32i1 loads into i32 loads, so a sequence like: define void @bits(<32 x i1>* %A, <32 x i1>* %B) { %a = load <32 x i1>, <32 x i1>* %A store <32 x i1> %a,

On 10 September 2012 06:44, Bob Wilson <bob.wilson at apple.com> wrote: > I don't know if anyone actually uses arm processors in big-endian mode, but it shouldn't be too hard to conditionalize it. If it does turn out to be difficult for some reason, we should at least have comments to indicate where the endian assumptions are being made. AFAICR, people used to use big-endian on

Hello Reed, Basic blocks need to end with a terminator instruction. There is an "unreachable" terminator instruction, whose documentation says: "the presence of this instruction indicates some higher level knowledge that the end of the block cannot be reached." (see include/llvm/IR/Instructions.h). I've been able to suppress the return using this. I'm not completely