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

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

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.

The obvious difference is that you're using --enable-optimized and implicitly --disable-assertions. If you run the tests with make check-all VERBOSE=1 'LIT_ARGS=-v ' > logfile and grep for FAILED in logfile, does what's listed there give any more details? (Quite possible in a Release-Asserts build it might not.) Cheers, Dave -----Original Message----- From: cfe-dev-bounces

Hello, I'm working on a binary translator project that emits an .ll file. I'm trying to debug it in Visual Studio and would like to be able to step through and see my generated .ll file in the debugger. Does LLVM support debug information corresponding to an input .ll file? My hunch is "no, as it expects debug info to come from Clang." I assemble it using: llc -filetype=obj

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 %

Sriram, This patch looks good. Please commit. ...and thanks for the data. -Andy On Jan 29, 2013, at 12:59 PM, "Murali, Sriram" <sriram.murali at intel.com> wrote: > Hello, > This patch aims to improve compile time performance by increasing the SCEV vector size in LoopStrengthReduce. It is observed that the BaseRegs vector size is 4 in most cases, and elements are

On Tue, May 12, 2009 at 6:26 PM, Dale Johannesen <dalej at apple.com> wrote: > > On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> >> wrote: >>> >>> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: >>> >>>> The error given: >>>>

The error given: ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : error C2668: 'abs' : ambiguous call to overloaded function f:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(539): could be 'long double abs(long double)' f:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(491): or 'float abs(float)'

Hello, This patch aims to improve compile time performance by increasing the SCEV vector size in LoopStrengthReduce. It is observed that the BaseRegs vector size is 4 in most cases, and elements are frequently copied when it is initialized as SmallVector<const SCEV *, 2> BaseRegs. Our benchmark results show that the compilation time performance improved by ~0.5%. Patch by Wan Xiaofei.

On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> > wrote: >> >> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: >> >>> The error given: >>> >>> ..\..\..\..\trunk\lib\Transforms\Scalar >>> \LoopStrengthReduce.cpp(1016) : >>> error C2668:

On May 12, 2009, at 10:59 PMPDT, OvermindDL1 wrote: >>>>> The error given: >>>>> >>>>> ..\..\..\..\trunk\lib\Transforms\Scalar >>>>> \LoopStrengthReduce.cpp(1016) : >>>>> error C2668: 'abs' : ambiguous call to overloaded function >>>>> >> I checked in a fix. > > Also, IndVarSimplify.cpp

On Tue, Jan 29, 2013 at 3:59 PM, Murali, Sriram <sriram.murali at intel.com> wrote: > Our benchmark results show that the compilation time performance improved by > ~0.5%. That's fairly small; what was the standard deviation, confidence interval, etc? -- Sean Silva

The compilation time is measured for different benchmarks while compiling a .bc file into a shared object. The improvement across the range of benchmarks is listed in following table. If the reason behind the need for other performance metrics is to identify possible measurement errors, then I think this table would be of some help. However, we do not have the standard deviation and confidence

Hi Jonas, Are you talking specifically about the induction variable? You might look at what I did for PowerPC's counter-based loops (lib/Target/PowerPC/PPCCTRLoops.cpp, etc.). -Hal ----- Original Message ----- > From: "Jonas Paulsson via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, March 28,

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