similar to: [LLVMdev] Argument to optimization pass

On 2010-11-10 12:58, Renato Golin wrote: > In a nutshell, the design decisions should be communicated more > effectively, and a Wiki is a great place to start. Peer reviewers > should communicate via the Wiki, so patchers could learn and plan > before the next iteration and reduce the cost for everybody. You may consider using a review tool rather than (or in addition to)

On 2011-08-09 16:48, John Criswell wrote: > On 8/9/11 6:49 AM, Bjorn Reese wrote: >> I have an optimization pass (FunctionPass) where I need to add global >> constructors. >> >> For cleaness sake I decided to add these in my own module. My module >> is created in my FunctionPass constructor: > > This is not how I would do it. A FunctionPass has

I have an optimization pass (FunctionPass) where I need to add global constructors. For cleaness sake I decided to add these in my own module. My module is created in my FunctionPass constructor: MyPass() : FunctionPass(ID), myModule("my_module", getGlobalContext()) {} I generate an llvm.global_ctor global variable in my module, and I add my global constructors

On 8/9/11 9:15 AM, Bjorn Reese wrote: > On 2011-08-09 16:48, John Criswell wrote: >> On 8/9/11 6:49 AM, Bjorn Reese wrote: >>> I have an optimization pass (FunctionPass) where I need to add global >>> constructors. >>> >>> For cleaness sake I decided to add these in my own module. My module >>> is created in my FunctionPass constructor:

On 8/9/11 6:49 AM, Bjorn Reese wrote: > I have an optimization pass (FunctionPass) where I need to add global > constructors. > > For cleaness sake I decided to add these in my own module. My module > is created in my FunctionPass constructor: This is not how I would do it. A FunctionPass has doInitialization() and doFinalization() methods that you can implement thatcan operate

Hi all, I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we support or, and, and conditional predicates (see Scott Mahlke's papers on this

On 11/21/2012 11:32 AM, Tobias Grosser wrote: > On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote: >> >> I'm thinking of this in terms of parallelization directives. The >> optimizations that rely on such annotations would need to be done as >> early as possible, before any optimization that could invalidate them. >> If the annotation can become false, you are

> On Jan 30, 2017, at 4:56 PM, Dehao Chen <dehao at google.com> wrote: > > > > On Mon, Jan 30, 2017 at 3:56 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: > On Mon, Jan 30, 2017 at 3:51 PM Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> On Jan 30,

On Wed, Oct 31, 2012 at 09:13:43PM +0100, Bjorn De Sutter wrote: > Hi all, > > I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we

On Mon, Jan 30, 2017 at 4:59 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > Another question is about PGO integration: is it already hooked there? > Should we have a more aggressive threshold in a hot function? (Assuming > we’re willing to spend some binary size there but not on the cold path). > > > I would even wire the *unrolling* the other way: just

FWIW, I'm good with the updated data, but I'd really like at least someone from Apple and someone from ARM to chime in here... CC-ing random people in the hope it helps... On Mon, Feb 13, 2017 at 8:30 AM Dehao Chen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for the comment. The performance experiments were performed on > Intel Sandybridge. Updated this info to

Recollected the data from trunk head with stddev data and more threshold data points attached: Performance: stddev/mean 300 450 600 750 403 0.37% 0.11% 0.11% 0.09% 0.79% 433 0.14% 0.51% 0.25% -0.63% -0.29% 445 0.08% 0.48% 0.89% 0.12% 0.83% 447 0.16% 3.50% 2.69% 3.66% 3.59% 453 0.11% 1.49% 0.45% -0.07% 0.78% 464 0.17% 0.75% 1.80% 1.86% 1.54% Code size: 300 450 600 750 403 0.56% 2.41% 2.74% 3.75%

Hi, Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100% accurate, but hopefully it helps to provide an overview of what's going on with compile time in LLVM and give a better understanding of what changes usually impact compile time.

On Mon, Jan 23, 2012 at 10:13 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Tue, 2012-01-17 at 13:25 -0600, Sebastian Pop wrote: >> Hi, >> >> On Fri, Dec 30, 2011 at 3:09 AM, Tobias Grosser <tobias at grosser.es> wrote: >> > As it seems my intuition is wrong, I am very eager to see and understand >> > an example where a search limit of 4000 is

On 02/10/2017 05:21 PM, Dehao Chen wrote: > Thanks every for the comments. > > Do we have a decision here? You're good to go as far as I'm concerned. -Hal > > Dehao > > On Tue, Feb 7, 2017 at 10:24 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > On 02/07/2017 05:29 PM, Sanjay Patel via llvm-dev wrote:

I had suggested having size metrics from somewhat larger applications such as Chrome, Webkit, or Firefox; clang itself; and maybe some of our internal binaries with rough size brackets? On Wed, Feb 1, 2017 at 4:33 PM Dehao Chen <dehao at google.com> wrote: > With the new data points, any comments on whether this can justify setting > fully inline threshold to 300 (or any other

I am thinking about another use of annotations that fits in a longer term vision, which centers around feeding compilers with information from higher-level tools such as precompilers. Deciding how to map a portable piece of software to a heterogeneous multicore processor and get the best performance for a range of widely varying architectures, requires much higher level code analysis than what is

On 02/07/2017 05:29 PM, Sanjay Patel via llvm-dev wrote: > Sorry if I missed it, but what machine/CPU are you using to collect > the perf numbers? > > I am concerned that what may be a win on a CPU that keeps a couple of > hundred instructions in-flight and has many MB of caches will not hold > for a small core. In my experience, unrolling tends to help weaker cores even more

Is packet-loss concealment influenced by the complexity setting?

When I compile llvm on my Linux box, it complains about missing STDOUT_FILENO in raw_ostream.cpp. The attached patch solves that problem. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: raw_ostream.cpp.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080822/401536e7/attachment.ksh>