similar to: [LLVMdev] RFC: LoopEditor, a high-level loop transform toolkit

On 28 Feb 2017, at 22:50, Michael Zolotukhin <mzolotukhin at apple.com<mailto:mzolotukhin at apple.com>> wrote: I also usually rerun suspiciously improved or regressed tests to verify the performance change. Most of the time, if it was just a noise, the test doesn’t appear on another run. I wish LNT (or any other script) could do that for me :) Michael Doesn't the lnt runtest nt

On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > Hi, > > Several passes would have troubles with such code (namely, GVN and > JumpThreading). Can you just choose not to run those particular passes? I suppose the big problem would be if there's a problem with the code generation and related stuff like instruction scheduling and

On Mon, Dec 11, 2017 at 3:37 PM, Mikhail Zolotukhin via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi Kim, > > On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at gmail.com> wrote: > > Hi Michael, > > On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin > <mzolotukhin at apple.com> wrote: > > > Nice to IWYU developers here:) I wonder how

Hi Michael, On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > > Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on > LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong). There are known problems with running IWYU over LLVM/Clang -- Zachary Turner made an attempt a while back to get it up and running.

This buildbot seems to have been failing continuously for a couple of weeks now ( http://lab.llvm.org:8011/builders/llvm-mips-linux/builds/14658 ) - is anyone watching it/caring about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at 11:34 PM Subject: buildbot failure in LLVM on llvm-mips-linux To: Ahmed Bougacha

I'm a little late to the party, but one observation that I haven't seen mentioned is that simply removing #includes and testing that the program compiles is not guaranteed to be a correct transformation. Imagine, for example, that a header file provides an overload of a function that is a better match than one found elsewhere. It will compile either way, but without the #include, you

On Mon, Dec 19, 2016 at 4:24 PM, Mikhail Zolotukhin <mzolotukhin at apple.com> wrote: > Hi Davide, > > Thanks for the analysis, it's really interesting! And I'm really glad that we now put more and more attention at the compile time! > > Just recently I've been looking into historical compile time data as well, and have had similar conclusions. The regressions

The reruns flag already does that. It helps a bit, but only as long as the the benchmark is flagged as regressed. > On May 18, 2015, at 8:28 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Mon, May 18, 2015 at 11:24 AM, Mikhail Zolotukhin <mzolotukhin at apple.com <mailto:mzolotukhin at apple.com>> wrote: > Hi Chris and others! > > I

Hi devs, Recently I came across an interesting testcase that LLVM failed to optimize well. The test does some image processing, and as a part of it, it traverses all the pixels and computes some value basing on the adjacent pixels. So, the hot part looks like this: for(y = 0..height) { for (x = 0..width) { val = 0 for (j = 0..5) { for (i = 0..5) { val += img[x+i,y+j] *

% clang -S -O3 -mcpu=cortex-a57 -ffast-math -Rpass-analysis=loop-vectorize dot.c dot.c:15:1: remark: loop not vectorized: value that could not be identified as reduction is used outside the loop [-Rpass-analysis=loop-vectorize] } ^ dot.c:15:1: note: could not determine the original source location for :0:0 I found “llvm-as < /dev/null | llc -march=aarch64 -mattr=help” which listed a

On Wed, Dec 21, 2016 at 8:07 AM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Dec 19, 2016 at 4:24 PM, Mikhail Zolotukhin > <mzolotukhin at apple.com> wrote: > > Hi Davide, > > > > Thanks for the analysis, it's really interesting! And I'm really glad > that we now put more and more attention at the compile time! >

The failure is a bit odd. LLVM is ignoring $PWD because it doesn't have the same inode as '.'. This causes the test failure because DW_AT_comp_dir and $PWD differ. However, $PWD and '.' should be the same inode since $PWD is a symlink to the current directory and stat() looks through symlinks. > Since this latest board only has two cores, it will run slower and it will need

> On Aug 23, 2015, at 11:35 AM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Sun, Aug 23, 2015 at 01:46:12AM +0100, Russell Wallace via llvm-dev wrote: >> On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <mzolotukhin at apple.com> >> wrote: >> >>> Hi, >>> >>> Several passes would have troubles

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

Hi Michael, Thank you very much. But idx_begin/idx_end iterators can only be used through a getelementptr instruction, right? However, I think value "i32* getelementptr inbounds (%struct.Args* @globalArg, i64 0, i32 2)" itself is not a getelementptr instruction, so? Or could you tell me how can I get a getelementptr instruction first from this value?

Hi Igor, On Oct 17, 2016, at 10:39 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: Hi Michael, Hi Igor, Hi Michael, Hi Michael, What I was referring to is that we can write something like this inside LPPassManager iteration: if

FWIW, r289813 also seems to be causing/exposing a miscompile of spec2006/perlbench on AArch64 (PR31449). -- Matt On Wed, Dec 21, 2016 at 11:07 AM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Dec 19, 2016 at 4:24 PM, Mikhail Zolotukhin > <mzolotukhin at apple.com> wrote: > > Hi Davide, > > > > Thanks for the analysis, it's

I would have replied to this thread sooner, but I was busy adding more instcombines. :) The motivation for r289855 is in the commit msg (I'm out of the office and can't look things up conveniently). Feel free to revert that and the follow ups, however, if that patch caused a noticeable slowdown, then it suggests we have a bigger problem?...that's a simple matcher (no value tracking

On 12/21/2016 03:36 PM, Sanjay Patel via llvm-dev wrote: > I would have replied to this thread sooner, but I was busy adding more > instcombines. :) > > The motivation for r289855 is in the commit msg (I'm out of the office > and can't look things up conveniently). Feel free to revert that and > the follow ups, however, if that patch caused a noticeable slowdown, >

On Sat, Nov 22, 2014 at 11:09 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Qiuping, > > If I'm reading the IR correctly, what you have is a > GetElementPtrConstantExpr [1]. It subclasses from llvm::Constant. > If you want the same code to handle GetElementPtrConstantExpr *and* GetElementPtrInst, you can use GEPOperator. > > Thanks, > --