similar to: [Constant Folder, InstCombine, ARM, AArch64] Question about constant folding of vector load

Displaying 20 results from an estimated 800 matches similar to: "[Constant Folder, InstCombine, ARM, AArch64] Question about constant folding of vector load"

2012 Sep 06
0
[LLVMdev] Unaligned vector memory access for ARM/NEON.
-----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:
2012 Sep 07
2
[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----- > 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
2012 Sep 06
0
[LLVMdev] Unaligned vector memory access for ARM/NEON.
Hi Pete, We ran into the same issue with generating vector loads/stores for vectors with less than word alignment. It seems we took a similar approach to solving the problem by modifying the logic in allowsUnalignedMemoryAccesses. As you and Jim mentioned, it looks like the vld1/vst1 instructions should support element aligned access for any armv7 implementation (I'm looking at Table A3-1
2012 Sep 06
2
[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 generating vector loads/stores for vectors > with less than word alignment. It seems we took a similar approach to > solving the problem by modifying the logic in allowsUnalignedMemoryAccesses. > > As you and Jim mentioned, it looks like the
2012 Sep 05
0
[LLVMdev] Unaligned vector memory access for ARM/NEON.
Hmmm. Well, it's entirely possible that it's LLVM that's confused about the alignment requirements here. :) I think I see, in general, where. I twiddled the IR to give it higher alignment (16 bytes) and get: extend: @ @extend @ BB#0: vldr d16, [r0] vmovl.s16 q8, d16 vstmia r1, {d16, d17} vldr d16, [r0, #8] add r0, r1, #16 vmovl.s16 q8, d16 vstmia
2012 Sep 06
2
[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 looks like a recent change (r161962?) did enable vld1 generation for this case (great!) on darwin, but not linux. I'm not sure if the effect of lowering load <4 x i16>* align 2 to vld1.16 this was intentional in this change or not. If so, my question is what is the preferable way to
2012 Sep 05
3
[LLVMdev] Unaligned vector memory access for ARM/NEON.
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 their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). Prior to the table, It does mention the accesses need to be "element" aligned, where I took
2012 Sep 06
1
[LLVMdev] Unaligned vector memory access for ARM/NEON.
On Sep 5, 2012, at 4:58 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hmmm. Well, it's entirely possible that it's LLVM that's confused about the alignment requirements here. :) > > I think I see, in general, where. I twiddled the IR to give it higher alignment (16 bytes) and get: > extend: @ @extend > @ BB#0: > vldr d16,
2012 Sep 05
0
[LLVMdev] Unaligned vector memory access for ARM/NEON.
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
2015 Jan 05
4
[LLVMdev] NEON intrinsics preventing redundant load optimization?
Hi all, Sorry for arriving late to the party. First, some context: vld1 is not the same as a pointer dereference. The alignment requirements are different (which I saw you hacked around in your testcase using attribute((aligned(4))) ), and in big endian environments they do totally different things (VLD1 does element-wise byteswapping and pointer dereferences byteswaps the entire 128-bit
2012 Sep 05
2
[LLVMdev] Unaligned vector memory access for ARM/NEON.
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
2012 Sep 07
0
[LLVMdev] Unaligned vector memory access for ARM/NEON.
> -----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
2013 Apr 19
0
[LLVMdev] MachineOperand SubReg
On Apr 19, 2013, at 7:18 AM, <dag at cray.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >>> A MachineOperand has both a getReg() and a getSubReg() interface. >>> For a physical register operand, is getReg() guaranteed to be the >>> "most super" register with getSubReg() providing the specific >>> subregister
2014 Dec 23
5
[LLVMdev] [RFC] Stripping unusable intrinsics
> On Dec 23, 2014, at 10:54 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > >> On Dec 23, 2014, at 10:41 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote: >> >> On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>>>> It should be
2018 Aug 10
2
llvm MemorySSA def-use chains
Hi, try adding some alias analysis to the pipeline: see examples in llvm/test/Analysis/MemorySSA/*.ll for example assume.ll has ; RUN: opt -aa-pipeline=basic-aa -passes='print<memoryssa>,verify<memoryssa>' without basic-aa the memory ssa will safely assume that the stores to %a and %d alias which may be proven disjoint by one of the alias analyses. On Thu, Aug 9, 2018 at 8:37
2013 May 22
2
[LLVMdev] Avoiding MCRegAliasIterator with register units
LLVM can model some quite complicated register banks now, and we even use registers to model some encoding constraints. For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class containing R0_R1, R2_R3, ... pseudo-registers. Sometimes ISAs also
2015 Jan 05
2
[LLVMdev] NEON intrinsics preventing redundant load optimization?
On 4 Jan 2015, at 21:06, Tim Northover <t.p.northover at gmail.com> wrote: >>> I’ve managed to replace the load/store intrinsics with pointer dereferences (along with a typedef to get the alignment correct). This generates 100% the same IR + asm as the auto-vectorized C version (both using -O3), and works with the toolchain in the latest XCode. Are there any concerns around doing
2018 May 04
2
RFC: Are auto-generated assertions a good practice?
Hello llvm-dev, On a recent code review I was asked to auto-generate assertion checks for my unit test. I wasn't aware that this was even possible. I am referring to the python `update` scripts under `utils` directory. My first reaction was wow! I found it very practical and useful. It saves you significant amount of time when writing a regression test. So I gave it a try. The generated
2014 Dec 10
2
[LLVMdev] NEON intrinsics preventing redundant load optimization?
On 9 Dec 2014, at 02:20, Jim Grosbach <grosbach at apple.com> wrote: >> On Dec 8, 2014, at 1:05 AM, Simon Taylor <simontaylor1 at ntlworld.com> wrote: >> >> On 8 Dec 2014, at 00:13, Renato Golin <renato.golin at linaro.org> wrote: >> >>> On 7 December 2014 at 19:15, Simon Taylor <simontaylor1 at ntlworld.com> wrote: >>>> Is
2013 Apr 19
2
[LLVMdev] MachineOperand SubReg
Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> A MachineOperand has both a getReg() and a getSubReg() interface. >> For a physical register operand, is getReg() guaranteed to be the >> "most super" register with getSubReg() providing the specific >> subregister information for the operand? If so then for my current >> purposes it seems I