search for: ghoflehner

Ping From: Mandeep Singh Grang [mailto:mgrang at codeaurora.org] Sent: Tuesday, February 03, 2015 4:34 PM To: 'llvmdev at cs.uiuc.edu' Cc: 'ghoflehner at apple.com'; 'apazos at codeaurora.org'; mgrang at codeaurora.org Subject: Question on Machine Combiner Pass Hi, In the file lib/CodeGen/MachineCombiner.cpp I see that in the function MachineCombiner::preservesCriticalPathLen we try to determine whether the new combined instr...

----- Original Message ----- > From: "Gerolf Hoflehner" <ghoflehner at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Jiangning Liu" <liujiangning1 at gmail.com>, "George Burgess IV" > <george.burgess.iv at gmail.com> > Sent: Monday, Septem...

...enchmarks that compile. This includes bzip2 (although different source base than in CINT2000), mcf, hmmer, sjeng, h364ref, astar, xalancbmk On Sep 15, 2014, at 11:59 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Gerolf Hoflehner" <ghoflehner at apple.com> >> To: "Jiangning Liu" <liujiangning1 at gmail.com>, "George Burgess IV" <george.burgess.iv at gmail.com>, "Hal Finkel" >> <hfinkel at anl.gov> >> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu> >> Sent...

On 20 August 2014 00:24, Gerolf Hoflehner <ghoflehner at apple.com> wrote: > My experience from leading BOFs at other conferences is more talk than action. So I suggest a different setup for this topic: how about having a working group meeting with participants who can commit time to work on this topic? Mine too, but in this case I have to say...

...is for a wide range of tests without having to manually modify each run line, perhaps as an environment variable/build time flag. Cheers, Amara > On Nov 27, 2017, at 6:18 PM, Vedant Kumar <vsk at apple.com> wrote: > >> >> On Nov 17, 2017, at 4:41 PM, Gerolf Hoflehner <ghoflehner at apple.com <mailto:ghoflehner at apple.com>> wrote: >> >> >> >>> On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> Hi Amara, >>> &g...

Hello All, The last two months I have been working on the design and implementation of a heterogeneous execution engine for LLVM. I started this project as an intern at the Qualcomm Innovation Center and I believe it can be useful to different people and use cases. I am planning to share more details and a set of patches in the next days. However, I would first like to see if there is an interest

----- Original Message ----- > From: "Renato Golin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Mehdi Amini" <mehdi.amini at apple.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, July 26, 2016 12:40:58 PM > Subject: Re: [llvm-dev] Target Acceptance Policy > > On 26 July 2016 at 18:33, Mehdi Amini

...Amini" <mehdi.amini at apple.com>, "LLVM Developers Mailing > List" <llvm-dev at lists.llvm.org>, "Philip Reames" > > <listmail at philipreames.com>, "Peter Cooper" <peter_cooper at apple.com>, > "Gerolf Hoflehner" <ghoflehner at apple.com> > > Sent: Friday, August 21, 2015 1:02:18 AM > > Subject: Re: [llvm-dev] [RFC] Generalize llvm.memcpy / llvm.memmove > intrinsics. > > > > Hi Hal > > > > > By this I assume you mean some new 'nooverlap' metadata? I don't > &g...

This conflict is with many optimizations incl. copy prop, coalescing, hoisting etc. Each could increase register pressure and with similar impact. Attempts to control the register pressure locally (within an optimization pass) tend to get hard to tune and maintain. Would it be a better way to describe eg in metadata how to undo an optimization? Optimizations that attempt to reduce pressure like

...doesn't reach a global, I think it would be much more effective to re-cast this as a forward analysis that determines all the memory locations in a function that come from outside the function, and use that to drive the no-alias responses. On Tue, Jul 14, 2015 at 12:12 PM Gerolf Hoflehner <ghoflehner at apple.com> wrote: > I wouldn’t be willing to give up performance for hypothetical issues. > Please protect all your changes with options. For some of your concerns it > is probably hard to provide a test case that shows an/the actual issue. > I certainly agree that it will be ve...

...obably carry a warning: Do what we say, not what we do. Cheers, Lang. On Thu, Aug 20, 2015 at 4:17 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Lang Hames" <lhames at gmail.com> > > To: "Gerolf Hoflehner" <ghoflehner at apple.com> > > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "LLVM Developers Mailing > List" <llvm-dev at lists.llvm.org>, "Hal Finkel" > > <hfinkel at anl.gov>, "Philip Reames" <listmail at philipreames.com>, &qu...

...M64 vs AArch64 % ARM64 vs AArch64 patched % SPEC 2000 art -10 -5 -1 bzip2 -3 5 5 crafty -5 1 3 gap -8 1 2 gzip 0 4 3 mcf -2 -1 -1 mesa -15 -3 -1 parser -10 -2 4 perlbmk 5 7 5 vortex -3 -6 -4 vpr -15 -1 0 From: Gerolf Hoflehner [mailto:ghoflehner at apple.com] Sent: Tuesday, April 08, 2014 4:46 PM To: Ana Pazos Cc: Tim Northover; LLVM Developers Mailing List Subject: Re: [LLVMdev] Proposal: AArch64/ARM64 merge from EuroLLVM Hi Ana, could you share the SPEC2000 data per suite and per benchmark? Thanks Gerolf On Apr 8, 2014,...

> On Apr 11, 2017, at 10:25 PM, Madhur Amilkanthwar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am interested in knowing more. > 1. What benchmarks does LLVM community use for compile-time study? I see CTMark, but is that the only one being analyzed? CTMark is not cast in stone. Its purpose is for the community to have a trackable proxy for the overall llvm test

...d be much > more effective to re-cast this as a forward analysis that determines all > the memory locations in a function that come from outside the function, and > use that to drive the no-alias responses. > > > > > > On Tue, Jul 14, 2015 at 12:12 PM Gerolf Hoflehner <ghoflehner at apple.com> > wrote: > > I wouldn’t be willing to give up performance for hypothetical issues. > Please protect all your changes with options. For some of your concerns it > is probably hard to provide a test case that shows an/the actual issue. > > > > I certainly a...

> On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Amara, > >> On Nov 10, 2017, at 9:12 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine

...'t reach a global, I think it would be much more effective to re-cast this as a forward analysis that determines all the memory locations in a function that come from outside the function, and use that to drive the no-alias responses. On Tue, Jul 14, 2015 at 12:12 PM Gerolf Hoflehner <ghoflehner at apple.com> wrote: I wouldn’t be willing to give up performance for hypothetical issues. Please protect all your changes with options. For some of your concerns it is probably hard to provide a test case that shows an/the actual issue. I certainly agree that it will be very hard to provid...

> On Sep 21, 2017, at 8:02 PM, River Riddle <riddleriver at gmail.com> wrote: > > Hey Gerolf, > > On Thu, Sep 21, 2017 at 7:10 PM, Gerolf Hoflehner <ghoflehner at apple.com <mailto:ghoflehner at apple.com>> wrote: > In general I would love to see an outliner at the IR level also. But rather than a comparison vs. the machine outliner I would like to learn more about how the core data structures between the outliners will be shared. > >...

...ecessary to preserve (1). For (2), this would be harder (what the vectorizer will or will not vectorize will likely change much more over time), but detecting problems here is certainly also very important. Thanks again, Hal ----- Original Message ----- > From: "Gerolf Hoflehner" <ghoflehner at apple.com> > To: "Hyojin Sung" <hsung at us.ibm.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, llvmdev at cs.uiuc.edu, llvmdev-bounces at cs.uiuc.edu > Sent: Wednesday, August 5, 2015 11:08:11 PM > Subject: Re: [LLVMdev] Improving loop vectorizer sup...

Hey Gerolf, On Thu, Sep 21, 2017 at 7:10 PM, Gerolf Hoflehner <ghoflehner at apple.com> wrote: > In general I would love to see an outliner at the IR level also. But > rather than a comparison vs. the machine outliner I would like to learn > more about how the core data structures between the outliners will be > shared. > The only structure that needs...

In lto+pgo some (5 out of 12 with usual suspect like perlbench and gcc among them using -flto -Wl,-mllvm,-use-cfl-aa -Wl,-mllvm,-use-cfl-aa-in-codegen) the CINT2006 benchmarks don’t compile. Has the implementation been tested with lto? If not, please stress the implementation more. Do we know reasons for gains? Where did you expect the biggest gains? Some of the losses will likely boil down to