similar to: LLVM v6.0 Internalize and GlobalDCE PASS can not work together?

Hi Hal, Thanks for your hint! $ /opt/llvm-svn/bin/opt -S -internalize -internalize-public-api-list=main -globaldce hello3.ll -o hello3.dce.ll    it works :) But I argue that `main` Function should be inserted into ExternalNames by default: Index: lib/Transforms/IPO/Internalize.cpp =================================================================== --- lib/Transforms/IPO/Internalize.cpp 

To reproduce the issue, please use the command line "opt -simplifycfg filename". target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %struct.G = type { %struct.ordered_index_node*, i32 } %struct.ordered_index_node = type { %struct.B, %struct.F } %struct.B = type { i32 } %struct.F = type { i32*, i32* }

Hi, Mehdi, For example, I have this very simple source code: void foo( int n, int array_x[]) { for (int i=0; i < n; i++) array_x[i] = i; } After I use "clang -emit-llvm -o bc_from_clang.bc -c try.cc", I get bc_from_clang.bc. With my code (using LLVM IRbuilder API), I get bc_from_api.bc. Attachment please find thse two files. I also past the IR here.

Thanks for your point that out. I just add DataLayout in my code such as "mod->setDataLayout("e-m:e-i64:64-f80:128-n8:16:32:64-S128");", still no luck. I'm really confused about this. Do I need to add more passes before -loop-unroll? On Sat, Aug 22, 2015 at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Aug 22, 2015, at 7:27 AM, Xiangyang

Hi the appended IR code does not optimize to my liking :) this is the interesting part in x86_64, that got produced via clang -Os: --- movq -16(%r12), %rax movl -4(%rax), %ecx andl $2298949, %ecx ## imm = 0x231445 cmpq $2298949, (%rax,%rcx) ## imm = 0x231445 leaq 8(%rax,%rcx), %rax cmovneq %r15, %rax movl $2298949, %esi ## imm = 0x231445 movq %r12, %rdi movq %r14,

When I compile two different modules using clang -O -S -emit-llvm I get different .ll files, no surprise. The first looks like double *v; double zap(long n) { double sum = 0; for (long i = 0; i < n; i++) sum += v[i]; return sum; } yielding @v = common global double* null, align 8 ; Function Attrs: nounwind readonly uwtable define double @zap(i64 %n) #0 { entry: %cmp4 =

Hi, The phase of instruction combine cannot handle the instruction %4 = select i1 %tobool.i, metadata !12, metadata !10 generated by the phase of CFG simplification and the compiler generates an assertion failure. I wonder whether this is valid LLVM IR: %4 = select i1 %tobool.i, metadata !12, metadata !10 Before CFGSimplify cond.true.i: ; preds = %entry

Verifying function running passes ... LV: Checking a loop in "bar" LV: Found a loop: L0 LV: Found an induction variable. LV: We need to do 0 pointer comparisons. LV: Checking memory dependencies LV: Bad stride - Not an AddRecExpr pointer %13 = getelementptr float* %arg2, i32 %1 SCEV: ((4 * (sext i32 {(256 + %arg0),+,1}<nw><%L0> to i64)) + %arg2) LV: Src Scev: {((4 * (sext

On some targets with limited addressing modes, getting that 64-bit relocatable but loop-invariant value into a register requires several instructions. I'd like those several instruction outside the loop, where they belong. Yes, my experience is that something (I assume instcombine) recanonicalizes. Thanks, Preston On Tue, Dec 8, 2015 at 11:21 PM, Mehdi Amini <mehdi.amini at

Hi, I have some IR module from random generation (mostly ineffective instructions). It has a function with void return, and two function arguments where one is a reference. Therefore, I expect every instruction not altering the value at the 2nd arguments address should be ineffective. Here is the function definition (see below for full ll): define void @_Z27entityMainDataInputCallbackdRd(double

I'm trying to make the IR "better", in a machine-independent fashion, without having to do any lowering. I've written code that rewrites GEPs as simple adds and multiplies, which helps a lot, but there's still some sort of re-canonicalization that's getting in my way. Is there perhaps a way to suppress it? Thanks, Preston On Wed, Dec 9, 2015 at 7:47 AM, Mehdi Amini

Thanks for your quick reply. Here its is: =========== ; ModuleID = 'simple_foo.c' source_filename = "simple_foo.c" target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.13.0" ; Function Attrs: noinline nounwind optnone ssp uwtable define i32 @foo(i32 %a, i32 %b, i32 %c) #0 { entry: %retval = alloca i32, align

I'm trying to use LLVM to create compiler-rt.o on Windows. I use this command from the compiler-rt project: [nix-shell:~/downloads/llvm-project/compiler-rt]$ clang -nostdlib -S -emit-llvm lib/builtins/udivti3.c -g -target x86_64-windows -DCRT_HAS_128BIT The resulting LLVM IR is: ================================================================= ; ModuleID = 'lib/builtins/udivti3.c'

Hello Has there been any progress on this topic ? The 3.9 optimizer output is still the same as I just looked. https://llvm.org/bugs/show_bug.cgi?id=24448 Ciao Nat! Sanjay Patel schrieb: > [cc'ing Zia] > > We have this transform with -Os for some cases after: > http://reviews.llvm.org/rL244601 > http://reviews.llvm.org/D11363 > > but something in this example is

This is my example (for.c): #include <stdio.h> int add(int a, int b) { return a + b; } int main() { int a, b, c, d; a = 5; b = 15; c = add(a, b); d = 0; for(int i=0;i<16;i++) d = add(c, d); } I run: $ clang -O0 -Xclang -disable-O0-optnone -emit-llvm for.c -S -o forO0.ll $ opt -O0 -S --loop-unroll --unroll-count=4 -view-cfg forO0.ll -o for-opt00-unroll4.ll

Frank, It looks like the loop vectorizer is unable to tell that the two stores in your code never overlap. This is probably because of the sign-extend in your code. Can you extend the indices to 64bit ? Thanks, Nadav On Oct 28, 2013, at 1:38 PM, Frank Winter <fwinter at jlab.org> wrote: > Verifying function > running passes ... > LV: Checking a loop in "bar" > LV:

I suppose your view is reasonable, and perhaps common. My own "taste" has always preferred machine-independent code that is as simple as possible, so GEPs reduced to nothing more than an add, etc, i.e., quite risc-like. Then optimize it to reduce the total number of operations (as best we can), then raise the level during instruction selection, taking advantage of available instructions.

I believe if you pass(iirc) -pass-remarks-missed=“gisel-*”, it’ll print the instruction it failed to legalize. Sent from my iPhone > On Oct 11, 2017, at 6:44 PM, S. Bharadwaj Yadavalli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks for your quick reply. > > Here its is: > > =========== > > ; ModuleID = 'simple_foo.c' > source_filename

Hi all, I'm trying to obtain a .ll with parameters name for every function. My simple c C is the following: int sum(int a, int b) { return a+b; } int main() { sum(1,2); } I obtain the .ll with the following commands: clang -emit-llvm sum.c -c llvm-dis-7 sum.bc The obtained .ll is: cat sum.ll ; ModuleID = 'sum.bc' source_filename = "sum.c" target datalayout =

A GEP can represent a potentially large tree of instructions. Seems like all the sub-trees are hidden from optimization; that is, I never see licm or value numbering doing anything with them. If I rewrite the GEPs as lots of little adds and multiplies, then opt will do a better job (I speculate this happens during lowering). One of the computations that's hidden in the GEP in my example is