search for: astigeevich

Hi Wei, Thank you for information. Please let me know about any progress in fixing the failures. I can help with checking that the final patch gives the same level of performance improvements. Kind regards, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM > -----Original Message----- > From: Wei Mi [mailto:wmi at google.com] > Sent: Friday, January 27, 2017 6:20 PM > To: Evgeny Astigeevich > Cc: llvm-dev; nd > Subject: Re: Reversion of rL292621 caused about 7% performance > regre...

...raham, Thank you for offering help. I am trying to create a reproducer. The problem is that the crashes happen whilst LTO is used. One thing I am sure about IR is broken at compile time. Thanks, Evgeny From: Graham Yiu <gyiu at ca.ibm.com> Date: Friday, 10 November 2017 at 16:09 To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: "junbuml at codeaurora.org" <junbuml at codeaurora.org>, "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, nd <nd at arm.com>, Tobias Grosser <tobias.grosser at inf.ethz.ch> Subject: Re: [llvm-dev] [RFC]...

...l push a fix soon (http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170123/424126.html). Thanks, Wei. On Fri, Jan 27, 2017 at 10:35 AM, Wei Mi <wmi at google.com> wrote: > Sure. Will keep you posted. > > Thanks, > Wei. > > On Fri, Jan 27, 2017 at 10:31 AM, Evgeny Astigeevich > <Evgeny.Astigeevich at arm.com> wrote: >> Hi Wei, >> >> Thank you for information. >> Please let me know about any progress in fixing the failures. >> I can help with checking that the final patch gives the same level of performance improvements. >> &g...

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 Subject: Re: [InstCombine] rL292492 affected LoopVectorizer and caused 17.30%/11.37% perf regressions on Cortex-A53/C...

...ng garbage. However a linker will have to have two versions of GC: one with parsing eh_frames and another without parsing. There can be input object files where .eh_frame is not split. -Evgeny From: Igor Kudrin <ikudrin at accesssoftek.com> Date: Friday, 10 November 2017 at 12:23 To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: nd <nd at arm.com>, "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly Hi Evgeny, > Yes, a linker needs some details but not all of them. It needs to kno...

...got: https://bugs.llvm.org/show_bug.cgi?id=35288 I have also found that LTO reverts everything the partial inliner has done. Maybe the partial inliner should not be used at the first LTO phase (compilation). I hope I’ll have a chance to look at the code size regressions this week. Thanks, Evgeny Astigeevich From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Evgeny Astigeevich via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Date: Saturday, 11 November 2017 at 17:21 To: Graham Yiu <gyiu at ca.ibm.com> Cc: &quot...

...whether it knows that in one place or two? What do you mean “one place or two”? If .eh_frame_hdr is not created a linker does not need to parse .eh_frame sections. It simply merges them into one section. The format of .eh_frame allows to do this without parsing .eh_frame sections. Thanks, Evgeny Astigeevich From: Igor Kudrin <ikudrin.dev at gmail.com> Date: Thursday, 9 November 2017 at 11:29 To: Rui Ueyama <ruiu at google.com>, Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, nd <nd at arm.com> Su...

...because we treat min/max like an optimization fence. If this is gonna be a long process to recover, this looks like something to be reverted in the 4.0 branch (unless I missed that there is a correctness fix involved?). — Mehdi > > > > On Mon, Jan 23, 2017 at 11:13 AM, Evgeny Astigeevich <Evgeny.Astigeevich at arm.com <mailto:Evgeny.Astigeevich at arm.com>> wrote: > 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?...

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 remove the hack in InstCombiner::visitICmpInst()? Yes. Although (this just came up in D28625 too) we might need to remov...

...rg/D29053> > > If we get lucky, we may be able to sidestep the min/max problem by folding harder before we reach that point in the optimization pipeline. > > > > — > Mehdi > > > >> >> >> >> On Mon, Jan 23, 2017 at 11:13 AM, Evgeny Astigeevich <Evgeny.Astigeevich at arm.com <mailto:Evgeny.Astigeevich at arm.com>> wrote: >> 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 th...

...these are compile-time errors I can help investigate on my end. Do you have something I can use to reproduce? Cheers, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: Graham Yiu/Toronto/IBM To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: "junbuml at codeaurora.org" <junbuml at codeaurora.org>, "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, nd <nd at arm.com>, "Tobias Grosser" <tobias.grosser at inf.ethz.c...

...the issue. What kind of help/support is needed? Should we (ARM Compilation Tools) start digging into the issue and fix it because the issue affects our future ARM Compiler 6 releases? We can provide help with validating that patches fix the issue and don’t introduce new ones. Kind regards, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Tuesday, January 24, 2017 4:55 PM To: Mehdi Amini Cc: Evgeny Astigeevich; llvm-dev; nd Subject: Re: [llvm-dev] [InstCombine] rL292492 affected LoopVectorizer and caused 17.30%/11.37% perf re...

...gressions in our benchmark on Cortex-M7/M4. In your commit comment I see it causes build bot failures. What kind are the failures? Compiler crashes or incorrect code generation? Will you fix them? We are interested in the changes because of performance improvements they give. Kind regards, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170127/70ee8352/attachment.html>

...ias, but actually correct by luck (or even wrong noalias, but does not result in miscompile). It would be useful to find out the set of missed noalias queries from GlobalModRef with your benchmark and examine if there is some improvement can be done. David On Fri, Jul 17, 2015 at 6:32 AM, Evgeny Astigeevich < Evgeny.Astigeevich at arm.com> wrote: > Yes, the regression is stable. I double checked this. A full benchmark > run consists of at least 10 sub-runs to validate the score. > > I also checked if there were regressions of this benchmark across > different ARM hardware versio...

Hi Sean, Thank you for reminding me. It looks like it get lost among tons of emails and other tasks. I’ll check if the code size issues still exist. Thanks, Evgeny Astigeevich From: Sean Fertile <sd.fertile at gmail.com> Date: Monday, 29 January 2018 at 19:52 To: Florian Hahn <Florian.Hahn at arm.com> Cc: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>, Graham Yiu <gyiu at ca.ibm.com>, "junbuml at codeaurora.org" <junbuml at codea...

...to have fizzled out and I would like to try to revive it. My intention is to pick up where Graham left off with enabling partial-inlining by default. On Sat, Dec 9, 2017 at 7:47 AM, Florian Hahn via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On 13/11/2017 14:47, Evgeny Astigeevich via llvm-dev wrote: > >> Hi Graham, >> >> I created a bug report with a reproducer for the failures I’ve got: >> https://bugs.llvm.org/show_bug.cgi?id=35288 >> >> > That bug should be fixed by https://reviews.llvm.org/rL320199 > > Cheers, > Florian...

On 10/25/2017 12:32 PM, Evgeny Astigeevich wrote: > > Hi Hal, > > I quickly checked the execution profile. It is real. The code changed > significantly. A number of the hottest regions changed. I’ll compare IRs. > Thanks. Obviously a 1000% execution performance regression seems problematic. -Hal > JFYI FreeBench/...

Can you say what Benchmark or give a test case so we understand the nature of the regression? As Gerolf said, that will be important to understand what is best to do. On Fri, Jul 17, 2015, 06:43 Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> wrote: > Yes, the regression is stable. I double checked this. A full benchmark > run consists of at least 10 sub-runs to validate the score. > > I also checked if there were regressions of this benchmark across > different ARM hardware version...

...2487 and rL292492. > If it's possible, can you remove that check locally, rebuild, > and try the benchmark again on your system? I'd love to know > if that change alone would solve the problem. Do you mean to remove the hack in InstCombiner::visitICmpInst()? Kind regards, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Friday, January 20, 2017 6:16 PM To: Evgeny Astigeevich Cc: llvm-dev; Renato Golin; t.p.northover at gmail.com; hfinkel at anl.gov Subject: Re: [InstCombine] rL292492 affected LoopVectorizer...

On Fri, Jul 17, 2015 at 9:13 AM Evgeny Astigeevich < evgeny.astigeevich at arm.com> wrote: > It’s Dhrystone. > Dhrystone has historically not been a good indicator of real-world performance fluctuations, especially at this small of a shift. I'd like to see if we see any fluctuation on larger and more realistic application benchmar...