similar to: [LLVMdev] Patch for Transform/LoopStrengthReduction/post-inc-icmpzero.ll test-failure

Hi Manish, Thanks for the patch, I'll check and commit. cheers, --renato PS: Patches are normally sent to llvm-commit list, unless they require a lot of discussion. On 15 January 2013 14:52, Manish Verma <manish.avtaar at gmail.com> wrote: > Hi, > > Transform/LoopStrengthReduction/post-inc-icmpzero.ll was failing for > clang-native-arm-cortex-a9 build-bot configuration.

Hi Renato, Thanks! I will make sure the patches are posted to the correct mailing list. Manish On Tue, Jan 15, 2013 at 3:04 PM, Renato Golin Linaro < renato.golin at linaro.org> wrote: > Hi Manish, > > Thanks for the patch, I'll check and commit. > > cheers, > --renato > > PS: Patches are normally sent to llvm-commit list, unless they require a > lot of

On Jan 21, 2013, at 12:37 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 21, 2013 at 11:49 AM, Andrew Trick <atrick at apple.com> wrote: > Moving to llvmdev... > > On Jan 21, 2013, at 11:37 AM, Nadav Rotem <nrotem at apple.com> wrote: > > > Hi Manish, > > > > Thank you for looking at this. Recently opt started using the

Hm, no. I expect byte addresses - everywhere. The compiler should not know that the arch needs word addresses. During lowering LOAD and STORE get explicit conversion operations for the memory address. Even if my arch was byte addressed the code would be false/illegal. Boris > Am 09.06.2020 um 19:36 schrieb Eli Friedman <efriedma at quicinc.com>: > > Blindly guessing here,

The IR after LSR is: *** IR Dump After Loop Strength Reduction *** ; Preheader: entry: tail call void @fill_array(i32* getelementptr inbounds ([10 x i32], [10 x i32]* @buffer, i32 0, i32 0)) #2 br label %while.body ; Loop: while.body: ; preds = %while.body, %entry %lsr.iv = phi i32 [ %lsr.iv.next, %while.body ], [ 0, %entry ] %uglygep = getelementptr

Hi. In my backend I get false code after using StrengthLoopReduction. In the generated code the loop index variable is multiplied by 8 (correct, everything is 64 bit aligned) to get an address offset, and the index variable is incremented by 1*8, which is not correct. It should be incremented by 1 only. The factor 8 appears again. I compared the debug output

On Jan 21, 2013, at 3:12 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 21, 2013 at 2:59 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jan 21, 2013, at 12:37 PM, Chandler Carruth <chandlerc at google.com> wrote: > >> On Mon, Jan 21, 2013 at 11:49 AM, Andrew Trick <atrick at apple.com> wrote: >> Moving to llvmdev...

Moving to llvmdev... On Jan 21, 2013, at 11:37 AM, Nadav Rotem <nrotem at apple.com> wrote: > Hi Manish, > > Thank you for looking at this. Recently opt started using the "-mtriple" command line flag to initialize the TargetMachine for IR-level transformations that use it. Currently only the following passes are using this feature: LSR, LowerSwitch, BBVectorizer and

On Mon, Jan 21, 2013 at 11:49 AM, Andrew Trick <atrick at apple.com> wrote: > Moving to llvmdev... > > On Jan 21, 2013, at 11:37 AM, Nadav Rotem <nrotem at apple.com> wrote: > > > Hi Manish, > > > > Thank you for looking at this. Recently opt started using the "-mtriple" > command line flag to initialize the TargetMachine for IR-level >

Moving to llvm-dev... On Jan 21, 2013, at 9:07 AM, Manish Verma <manish.verma at arm.com> wrote: > Hi Andy, > > I have been able track down the reason for the difference in output > generated by > opt. The difference is caused when the target triple specified in the > test-case > is not a supported target for opt/clang/llvm. In this case, opt doesn't thow > an

Hi, I found that building LLVM in single-threaded mode with CMake is failing because some object files still have references to pthread routines. There are two instances of the build failure happening. $ cmake .../llvm/ -DLLVM_ENABLE_THREADS=0 $ make -j8 check-all % Linking CXX executable IRTests ../../lib/libgtest.a(gtest.cc.o): In function

> cmpq %rbx, %r14 > jne .LBB0_1 > > LLVM can perform compare-jump fusion, it already does in certain cases, but > not in the case above. We can remove the cmp above if we were to perform > the following transformation: Do you mean branch-fusion (https://en.wikichip.org/wiki/macro-operation_fusion)? Is there any more limitation why these two or not fused? > -----Original

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

Manish Verma <manish.avtaar at gmail.com> writes: > I am attaching a patch which fixes the above mentioned failures. Could you > please review the patch? [snip] > index 79eb098..6419653 100644 > --- a/unittests/Support/ManagedStatic.cpp > +++ b/unittests/Support/ManagedStatic.cpp > @@ -9,7 +9,7 @@ > #include "llvm/Support/ManagedStatic.h" > #include

> From: fglaser at apple.com <fglaser at apple.com> On Behalf Of escha at apple.com > Sent: Saturday, April 7, 2018 8:22 AM > >> I realize this is a micro-op saving a single cycle.  But this reduces the instruction count, one less >> instr to decode in a potentially hot path. If this all makes sense, and seems like a reasonable addition >> to llvm, would it make

> > I realize this is a micro-op saving a single cycle. But this reduces the instruction count, one less > instr to decode in a potentially hot path. If this all makes sense, and seems like a reasonable addition > to llvm, would it make sense to implement this as a supplemental LSR formula, or as a separate pass? This seems reasonable to me so long as rbx has no other uses that

The following failures are consistent on buildbot (and my local box). The Clang one I think it's assuming an Intel box, the other two look like the FileCheck are not good enough. http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4305 Clang :: CodeGen/compound-assign-overflow.c LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll LLVM ::

On 8 January 2013 17:01, Dmitri Gribenko <gribozavr at gmail.com> wrote: > r171853 for this one. Build not finished yet. > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4312 Thanks!! > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > > Looks like a better regex can fix this. > I think both of them are just bad FileChecks... This is

Hi, I am trying to locate the passes run by clang/opt when it is passed the option -O3. Can someone point me where to look at? Eventually, I want to turn off just the LoopStrengthReduction pass in the -O3 set of default passes. Thanks, Best Regards, Nitish -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, 2012-02-08 at 17:26 -0800, Chris Lattner wrote: > On Feb 7, 2012, at 12:10 PM, Hal Finkel wrote: > >>> 1. "Target Data" for vectorization - I think that in order to improve > >>> the vectorization quality, the vectorizer will need more information > >>> about the target. This information could be provided in the form of a > >>>