similar to: [LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll

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 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

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 >

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...

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

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, Transform/LoopStrengthReduction/post-inc-icmpzero.ll was failing for clang-native-arm-cortex-a9 build-bot configuration. The reason for the failure was the test was using hardcoded names. The attached patch fixes this failure by replacing the hard-coded variables names with pattern-matched variable names. I have checked that the test pass after applying the patch. Could somebody please

On 04/01/2014 15:19, llvm.buildmaster at lab.llvm.org wrote: > The Buildbot has detected a new failure on builder clang-native-arm-cortex-a9 while building cfe. > Full details are available at: > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/14552 > > Buildbot URL: http://lab.llvm.org:8011/ > > Buildslave for this Build: as-bldslv1 > > Build

I have a few questions regarding cost calculation in loop strength reduction. 1. Ignoring LSR uses of kind ICmpZero. These usually come from the loop latch conditions. On Hexagon most loops that would contain such a LSR use are going to be converted to hardware loops and the entire check will disappear. There is no need to analyze these cases in LSR. In fact, completely ignoring them improves

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

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 Tue, Jan 8, 2013 at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote: > The following failures are consistent on buildbot (and my local box). [...] > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.ll It is interesting that I don't see this on my ARM box. Instead I see these: Failing

On Tue, Jan 8, 2013 at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote: > 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 ::

Hi Tim, Thank you for your reply. It actually helped a lot to narrow the issue, as previously I didn’t even know where to look. I have been following the code in the debugger, specially the LSRInstance::SolveRecurse function. This function traverses recursively all possible ‘Formulae’, and determines the best instruction combination for the loop generation, based on minimal cost. The

On Tue, Jan 8, 2013 at 5:04 AM, Renato Golin <renato.golin at linaro.org> wrote: > 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 ::

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

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,

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

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

On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > The error given: > > ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : > error C2668: 'abs' : ambiguous call to overloaded function > > It should be rather obvious from the message. The error is in > LoopStrengthReduce.cpp on line 1016: > (unsigned(abs(SInt)) < SSInt || (SInt %