similar to: Cost model is missing in InstCombiner

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Shixiong Xu" <shixiong at cadence.com> > Cc: llvm-dev at lists.llvm.org > Sent: Thursday, August 18, 2016 11:05:35 AM > Subject: Re: [llvm-dev] Cost model is missing in InstCombiner > +David M. > > On Aug 17, 2016, at 3:48 AM, Shixiong Xu

Hi, I noticed that the dead instructions collected when build vplan are invariant to different ranges of VFs since the original loop is not changed. Maybe DeadInstructions should be treated as a data member of LoopVectorizationPlanner and initialized by collectTriviallyDeadInstructions() in plan()? Cheers, Shixiong (Jason) Xu -------------- next part -------------- An HTML attachment was

Hello All, I am trying to understand the demanded-bits pass. The example in the source code (below) seems quite explicit. In the example, only 16 bits from a 32 bit variable in IR are demanded and therefore the variable is truncated to a 16 bit variable. %1 = add i32 %x, %y %2 = trunc i32 %1 to i16 However I was wondering if for example, the addition demanded, say 18 bits, would this pass

Hi, Current loop vectorizer uses a range of vectorization factors computed by MaxVF. For each VF, it setups unform and scalar info before building VPlan and the final best VF selection. The best VF is also selected within the VF range. for (unsigned VF = 1; VF <= MaxVF; VF *= 2) { // Collect Uniform and Scalar instructions after vectorization with VF.

On 08/02/2012 11:11 AM, Chris Lattner wrote: >> A new self-contained `LibCallSimplifier` class will be created. An instance >> of the class will be instantiated when running the `InstCombiner` pass. It's >> folding functionality will be invoked from `InstCombiner::tryOptimizeCall` and >> the implementation will be table-driven like `SimplifyLibCalls`. All of the

On Aug 1, 2012, at 9:49 PM, Meador Inge <meadori at codesourcery.com> wrote: > Hi All, > > I finally got around to cleaning up my proposal to merge `SimplifyLibCalls` > into `InstCombiner`. There is still an open question or two and I am sure > there are parts that could be better specified, but this is good enough to > discuss. Feedback is most welcome. Fantastic,

Hi All, I finally got around to cleaning up my proposal to merge `SimplifyLibCalls` into `InstCombiner`. There is still an open question or two and I am sure there are parts that could be better specified, but this is good enough to discuss. Feedback is most welcome. Abstract ======== This proposal is an attack plan for PR11895 [1]. Currently within LLVM we have two passes that are used to

On Aug 3, 2012, at 12:56 PM, Meador Inge <meadori at codesourcery.com> wrote: >>> An option for enabling/disabling library call simplification in `InstCombiner` >>> will be available. For backwards compatibility perhaps it should remain >>> '-simplify-libcalls'. The `NumSimplified` and `NumAnnotated` statistics shall >>> be added to

On 01/15/2018 12:21 PM, Demikhovsky, Elena wrote: > Hi all, >   > I’m working on an out-of-tree target and encountered the following > problem: >   > InstCombiner “normalizes” GEPs and extends Index operand to the > Pointer width. > It works fine if you can convert pointer to integer for address > calculation and I assume that all registered targets do this. >   >

> On 15 Jan 2018, at 18:21, Demikhovsky, Elena via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I’m working on an out-of-tree target and encountered the following problem: > > InstCombiner “normalizes” GEPs and extends Index operand to the Pointer width. > It works fine if you can convert pointer to integer for address calculation and I assume

Hi all, I'm working on an out-of-tree target and encountered the following problem: InstCombiner "normalizes" GEPs and extends Index operand to the Pointer width. It works fine if you can convert pointer to integer for address calculation and I assume that all registered targets do this. The target I'm working on has very restricted ISA for the

On 01/15/2018 12:59 PM, Demikhovsky, Elena wrote: > > I tried to retrieve anything from DataLayout. It contains pointer > size, but how can I conclude that the GEP index can’t be widened? > I meant that we'd add a new field giving the preferred size for indexing arithmetic.  On the other hand, in your case, and in general, would it make sense to prevent widening beyond the largest

I tried to retrieve anything from DataLayout. It contains pointer size, but how can I conclude that the GEP index can't be widened? - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, January 15, 2018 20:34 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) <spatel at

Hi Sanjay, The benchmark source file: http://www.llvm.org/viewvc/llvm-project/test-suite/trunk/SingleSource/Benchmarks/Shootout/sieve.c?view=markup Clang options used to produce the initial IR: clang -DNDEBUG -O3 -DNDEBUG -mcpu=cortex-a53 -fomit-frame-pointer -O3 -DNDEBUG -w -Werror=date-time -c sieve.c -S -emit-llvm -mllvm -disable-llvm-optzns --target=aarch64-arm-linux Opt options: opt -O3

Thank you for information. I’ll build clang without the hack and re-run the benchmark tomorrow. -Evgeny From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Sunday, January 22, 2017 8:00 PM To: Evgeny Astigeevich Cc: llvm-dev; nd Subject: Re: [InstCombine] rL292492 affected LoopVectorizer and caused 17.30%/11.37% perf regressions on Cortex-A53/Cortex-A15 LNT machines > Do you mean to

Hi, We found that today's 17.30%/11.37% performance regressions in LNT SingleSource/Benchmarks/Shootout/sieve on LNT-AArch64-A53-O3__clang_DEV__aarch64 and LNT-Thumb2v7-A15-O3__clang_DEV__thumbv7 (http://llvm.org/perf/db_default/v4/nts/daily_report/2017/1/20?filter-machine-regex=aarch64%7Carm%7Cthumb%7Cgreen) are caused by changes [rL292492] in InstCombine: https://reviews.llvm.org/D28406

Confirm there is no change in IR if the hack is disabled in the sources. David wrote that these instructions are created by SCEV. Are other targets affected by the changes, e.g. X86? Kind regards, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Sunday, January 22, 2017 10:45 PM To: Evgeny Astigeevich Cc: llvm-dev; nd

Hi all, I have a query regarding Cost Table for AVX2 in TargetTransformInfo. The table consist of entries for shift and div operations only. There are no entries for ADD, SUB and MUL for AVX2 cost table. Those entries are present in Cost Table for AVX. The reason for query is - when my sub target feature is AVX2, in SLP Vectorization, while calculating scalar cost of ADD, it doesn't see

> On Jan 23, 2017, at 3:48 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > All targets are likely affected in some way by the icmp+shl fold introduced with r292492. It's a basic pattern that occurs in lots of code. Did you see any perf wins on your targets with this commit? > > Sadly, it is also likely that many (all?) targets are negatively

Thanks Nadav for the info. It clears my query :) Yes its an integer ADD, and since AVX2 supports 256 bits integer arithmetic, so its cost is less than AVX1. One query though - shouldn't then the cost of integer ADD/SUB/MUL (which would be 1) be explicitly specified in AVX2 cost table? Because right now this entry is missing and cost of these operations are taken from BaseTTI (which is