search for: load16

...where in DSP functions. It’d be pretty nice if the compiler could do it too. There is one alternate approach that I recall, which looks like this: Original code (example, pseudocode): int add_delta_256(uint8 *in1, uint8 *in2) { int accum = 0; for (int i = 0; i < 16; ++i) { uint8x16 a = load16(in1 + i *16); // NOTE: takes an extra addressing op because x86 uint8x16 b = load16(in2 + i *16); // NOTE: takes an extra addressing op because x86 accum += psadbw(a, b); } return accum; } end of loop: inc i cmp i, 16 jl loop LSR’d code: int add_delta_256(uint8 *in1, uint8 *in2) { in...

I am attempting to implement a minor loop strength reduction optimization for targets that support compare and jump fusion, specifically TTI::canMacroFuseCmp(). My approach might be wrong; however, I am soliciting the idea for feedback, so that I can implement this correctly. My plan is to add a Supplemental LSR formula to LoopStrengthReduce.cpp that optimizes the following case, but perhaps

On 07/04/2013 01:39 PM, Stéphane Letz wrote: > Hi, > > Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some

Hi, Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some informations that are needed by the vectorization passes to

...inue, or q <return> to quit--- > ??? 0x7f73f050c000->0x7f73f050d000 at 0x07810000: load15a ALLOC LOAD > READONLY CODE HAS_CONTENTS > ??? 0x7f73f050d000->0x7f73f050d000 at 0x07811000: load15b ALLOC > READONLY CODE > ??? 0x7f73f050f000->0x7f73f050f000 at 0x07811000: load16 ALLOC READONLY > ??? 0x7f73f070e000->0x7f73f070f000 at 0x07811000: load17 ALLOC LOAD > HAS_CONTENTS > ??? 0x7f73f070f000->0x7f73f0710000 at 0x07812000: load18a ALLOC LOAD > READONLY CODE HAS_CONTENTS > ??? 0x7f73f0710000->0x7f73f0710000 at 0x07813000: load18b ALLOC &gt...

On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > >

...pe <return> to continue, or q <return> to quit--- 0x7f73f050c000->0x7f73f050d000 at 0x07810000: load15a ALLOC LOAD READONLY CODE HAS_CONTENTS 0x7f73f050d000->0x7f73f050d000 at 0x07811000: load15b ALLOC READONLY CODE 0x7f73f050f000->0x7f73f050f000 at 0x07811000: load16 ALLOC READONLY 0x7f73f070e000->0x7f73f070f000 at 0x07811000: load17 ALLOC LOAD HAS_CONTENTS 0x7f73f070f000->0x7f73f0710000 at 0x07812000: load18a ALLOC LOAD READONLY CODE HAS_CONTENTS 0x7f73f0710000->0x7f73f0710000 at 0x07813000: load18b ALLOC READONLY CODE 0x7f73f07...