similar to: [LLVMdev] How to decide whether a function is executed or not

On 20 May 2014 16:08, RICHARD STUCKEY <richard.stuckey at virgin.net> wrote: > Consider a function which contains an infinite loop: any algorithm which > could determine whether that function is called or not would effectively be > an algorithm that could determine whether the program containing that > function halts or not. Equally, deciding whether the function contains an

Hello Is there a "generic" pragma that is supported by LLVM and is visible by optimization passes? or any other way for a programmer to pass meta-data information to the compiler? I am writing an analysis pass that could benefit from user provided information. At this stage, I could like to keep the kind of information that the user can provide as general as possible.

Pre-empting Chris's inevitable response: don't add intrinsics! I really like the 'disappearing function calls' idea. Chris suggested practically the same thing for a previous question about adding BigInt support. Anthony, whichever route you take in the end, please consider documenting your 'code adventure' on the wiki so others can learn from your experience. Justing

You could encode this information as simple library function calls and then find them again in the generated LLVM IR. The client then just needs a header declaring the functions and information on what they mean. Since there are never any definitions of them they won't end up going anywhere. A more ambitious plan would be to modify llvm-gcc with new __builtins and create intrinsics in

There is PostDominatorTree for determining post-dominance. Even if A post-dominates B and B is executed, that doesn't guarantee that A will be executed. For example, there could be an infinite loop in-between. Strong post-dominance makes the stronger guarantee that there will be no infinite loop from B to A. Do we have anything in LLVM for determining strong post-dominance and in general for

Hello all, I am writing test cases which are dedicated to be executed by llvm-lit. Most of my test cases have the same logic but different types. For example: // RUN: %clang_cc1 -fsyntax-only func (int a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (char a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (unsigned a) { a = 3; } Now I put them in three different test cases but it

Dear mailing list, I tried to run the example for the conditional bootstap written in the help file of censboot. I got the following result: STRATIFIED CONDITIONAL BOOTSTRAP FOR CENSORED DATA Call: censboot(data = aml, statistic = aml.fun, R = 499, F.surv = aml.s1, G.surv = aml.s2, strata = aml$group, sim = "cond") Bootstrap Statistics : original bias std. error t1*

Thanks for the quick responses. "disappearing function calls" is by far the preferred way for me, as I want my pass to work with standard LLVM and not a hacked version that supports extra pragmas, or intrinsics. I am just new to LLVM and wanted to make sure that there isn't already a mechanism for passing meta-data between the user and the optimizer. I am planning to

Hi, Simple description of the problem below. I have code coming into pruneEH as follows fn a { entry: call fn b ... for_cond: %i = phi [1, entry] [%x, for_body] cmp $i with someval cond-br for_body or for_exit for_body: ... $x = $i + 1 branch for_cond for_exit ... } PruneEH determines that the call to fn-b won't return. The code is modified thus. fn a { entry: call fn b unreachable insn

On Wed, Sep 2, 2015 at 5:36 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > Coremark really isn't a good enough test - have you run the LLVM test suite > with this patch, and what were the performance differences? For the test suite single source benches, the 235 tests improved performance, 2 regressed and 705 were unchanged. That seems very optimistic.

Hello, Richard Thanks a lot ! On Fri, Dec 19, 2014 at 10:04 AM, RICHARD STUCKEY < richard.stuckey at virgin.net> wrote: > > Hi, Hui Zang, > > It helps to remember that at runtime a variable of a structure type has to > be allocated store, and to think about how that variable is laid out in > store. > > You must use createMemberType to create a DIType for *each*

Hal Finkel wrote: > But it is not all optimizations that are the problem. Rather, it > seems like a select few (e.g. things involving collapsing allowed > non-determinism in atomics), and losing those optimizations seems > better than generally losing function-attribute deduction. If we go by the langref, then optimizations that fold undef are also problematic (though most C/C++

In your original file, %6 is defined in if.end11 and is used in cond.end. if.end11 branches to cond.true and cond.false, both of which branch unconditionally to cond.end. Therefore %6 dominates its use. In your second file %18 is defined in end.11 and used in cond.end. However, end.11 no longer dominates cond.end because you have rewritten all branches to go through the switch statement in

Thanks to David's help I subset my large data set and produced a smaller one for a single stream and 7 factors of interest. The structure of this data frame is: str(burns.tds.anal) 'data.frame': 718 obs. of 4 variables: $ site : Factor w/ 143 levels "BC-0.5","BC-1",..: 1 1 4 6 4 4 4 5 5 5 $ sampdate: Date, format: "1996-06-02"

On Mon, Dec 18, 2017 at 5:46 PM Xinliang David Li <davidxl at google.com> wrote: > The introduction of cleanup.cond block in b.ll without loop-rotation > already makes the layout worse than a.ll. > > > Without introducing cleanup.cond block, the layout out is > > entry->while.cond -> while.body->ret > > All the arrows are hot fall through edges which is

Hi, I am investigating a performance degradation between llvm-3.1 and llvm-3.2 (Note: current top-of-tree shows a similar degradation) One issue I see is the following: - 'loop invariant code motion' seems to be depending on the result of the 'reassociate expression' pass: In the samples below I observer the following behavior: Both start with the same expression: %add = add

As far as I can understand of the code, the Reassociate tries to achieve this result by its "ranking" mechanism. If it dose not, it is not hard to achieve this result, just restructure the expression in a way such that the earlier definition of the sub-expression is permute earlier in the resulting expr. e.g. outer-loop1 x= outer-loop2 y =

On Apr 25, 2013, at 10:51 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > It's an interesting problem. > The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. > Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf > I can't tell, quickly, what's going on

It's an interesting problem. The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf I can't tell, quickly, what's going on in Reassociate; as usual, the documentation resolutely avoids giving any credit for the ideas. Why is that?

Hi, That's what the DecoderMethod is for. Similarly ParserMatchClass for the asm parser and PrintMethod for the asm printer: def CondCodeOperand : AsmOperandClass { let Name = "CondCode"; } def pred : PredicateOperand<OtherVT, (ops i32imm, i32imm), (ops (i32 14), (i32 zero_reg))> { let PrintMethod = "printPredicateOperand";