search for: getunrollingpreferences

...n > performs the dodgy transformation and changes the output. > > I've not tracked down quite how Clang sets that extra > "-unroll-runtime" option (I'd be interested to know myself, actually, > having failed). It doesn't, but the backend can by overriding TTI::getUnrollingPreferences or setting LoopMicroOpBufferSize in the processor scheduling model. -Hal > > Cheers. > > Tim. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/lis...

...ction-cache > pressure is an important consideration, but the code size changes > here seems small. > >> >> Is the proposed change universal? Is there a way to undo it? > > All of the unrolling thresholds should be target-adjustable using > the TTI::getUnrollingPreferences hook. > > -Hal > > >> >> On Tue, Feb 7, 2017 at 3:26 PM, Dehao Chen via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Ping... with the updated code size impact data, any more >&...

...more opportunities to hide latency. Obviously, instruction-cache pressure is an important consideration, but the code size changes here seems small. > > Is the proposed change universal? Is there a way to undo it? All of the unrolling thresholds should be target-adjustable using the TTI::getUnrollingPreferences hook. -Hal > > On Tue, Feb 7, 2017 at 3:26 PM, Dehao Chen via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Ping... with the updated code size impact data, any more comments? > Any more data that would be interestin...

...oad() |> llvm.x86.masked.compressstore() |> |> Cons: |> |> TTI will need to deal with Loop Info, SCEVs and other loop analysis |> info that it does not have today. (I do not like this way) | |Giving TTI the loop and other analyses, in itself, does not bother me. |getUnrollingPreferences takes a Loop*. I'm more concerned about |how cleanly we could integrate everything. | |> Or we'll need to introduce TLV - Target Loop Vectorizer - a new class |> that handles all target specific cases. This solution seems more |> reasonable, but too heavy just for compres...

I'm investigating a miscompilation bug ( http://llvm.org/bugs/show_bug.cgi?id=19823 ), but I've run into a problem: the output of the program is different when I compile the IR with clang compared to opt | llc | clang. Any clues on how to resolve this difference? $ ./opt -O1 19823.ll | ./llc | ./clang -x assembler - -o a.out ; ./a.out ; echo $? 1 $ ./opt -O2 19823.ll | ./llc | ./clang -x

...e latency. Obviously, instruction-cache pressure is an > important consideration, but the code size changes here seems small. > > > Is the proposed change universal? Is there a way to undo it? > > > All of the unrolling thresholds should be target-adjustable using the > TTI::getUnrollingPreferences hook. > > -Hal > > > > On Tue, Feb 7, 2017 at 3:26 PM, Dehao Chen via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Ping... with the updated code size impact data, any more comments? Any > more data that would be interesting to collect? > > Thanks, &...

Dear all, Some benchmarking experimentation I`ve done recently -- all on AArch64 -- has shown that it might be beneficial for all AArch64 targets to have a positive LoopMicroOpBufferSize, whereas the default that applies to all ISAs seems to be zero. Although I`ve tried going as far down the rabbit hole as I can, I haven`t found a way to set DefaultLoopMicroOpBufferSize on a per-ISA basis or

| |Hi Elena, | |Technically speaking, this seems straightforward. | |I wonder, however, how target-independent this is in a practical |sense; will there be an efficient lowering when targeting any other |ISA? I don't want to get into the territory where, because the |vectorizer is supposed to be architecture independent, we need to |add target-independent intrinsics for all

Ping... with the updated code size impact data, any more comments? Any more data that would be interesting to collect? Thanks, Dehao On Thu, Feb 2, 2017 at 2:07 PM, Dehao Chen <dehao at google.com> wrote: > Here is the code size impact for clang, chrome and 24 google internal > benchmarks (name omited, 14 15 16 are encoding/decoding benchmarks similar > as h264). There are 2

...e latency. Obviously, instruction-cache pressure is an > important consideration, but the code size changes here seems small. > > > Is the proposed change universal? Is there a way to undo it? > > > All of the unrolling thresholds should be target-adjustable using the > TTI::getUnrollingPreferences hook. > > -Hal > > On Tue, Feb 7, 2017 at 3:26 PM, Dehao Chen via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Ping... with the updated code size impact data, any more comments? Any > more data that would be interesting to collect? > > Thanks, > Dehao...