similar to: [LLVMdev] Canonicalization of select vs shift

Look at this silly function: $ cat small.c unsigned f(unsigned a, unsigned *p) { unsigned x = a/4; p[0] = x; p[1] = x+x; return p[1] - 2*p[0]; } GCC turns this into straightforward code and figures out the 0 return value: shrl $2, %edi movl %edi, (%rsi) addl %edi, %edi movl %edi, 4(%rsi) movl $0, %eax ret LLVM optimizes the code: $ clang -O -S -o- small.c -emit-llvm define i32

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* }

In the section about poison values, the LLVM language reference manual says: "Values other than phi nodes depend on their operands." This implies that a select instruction's output can be poisoned by its not-selected argument value. If select were poisoned only by its selected argument, we would expect this fact to be mentioned specifically, as it is for phi. Next I'll

Hallo. I wanted to use the DSA from the poolalloc project as a starting point for static C code analysis (for me it has some benefits to work on LLVM-IR (generated by clang) instead of C code). Currently there is no poolalloc version 3.3. Therefore I wrote a quick patch to make poolalloc 3.2 compile with llvm 3.3 (mostly adaptions to file relocations were necessary). The patch is attached as

Hello everyone, please I need your help. To reproduce my problem I created simple pass for backends (TestPass.cpp in attached files). That pass I call from Mips backend in this way (MipsTargetMachine.cpp): bool MipsPassConfig::addPreRegAlloc() { addPass(createTestPass()); return false; } The problem becomes, when I am trying compile file ldtoa.ll (in attached files). Compiling

After I spend some time working with the function attribute* deduction pass** [1,3], I would like to propose a "proper" organization***. Why? Because we do not derive nearly as many attributes as we could****, while we do maintain various (separate and diffently organized) "data-flow-like analyses" to do so. What else? I propose a single optimistic data-flow

Ok, this makes sense. So, my follow up is then why, as in Mips, R600, etc... the bit value is checked in the tablegen. Seems that we should expect it to fit anyways if it still exists at this point? I'm having a hard time trying to get shl to take a PatLeaf for Imm instead of an ImmLeaf. On Mon, Apr 20, 2015 at 4:11 PM, David Majnemer <david.majnemer at gmail.com> wrote: > >

Hi everyone, I am wondering what¹s stopping the LLVM optimizer (opt -O3) from eliminating the apparently useless « icmp sgt » instruction in the following piece of LLVM IR. > ; ModuleID = 'lambda-opt.bc' > target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" > target triple = "x86_64-apple-macosx10.10.0" > > ; Function

With the optimization patch I emailed, clang compiles bool f(bool *x) { return *x; } to define zeroext i1 @_Z1fPb(i8* nocapture %x) nounwind uwtable readonly { entry: %0 = load i8* %x, align 1, !tbaa !0, !range !3 %tobool = icmp ne i8 %0, 0 ret i1 %tobool } Which I think is the perfect IL if we are going to return an i1. Unfortunately, this still codegens to cmpb $0, (%rdi)

Hi, While comparing the code by LLVM and GCC for some major libraries, I found that LLVM fails to apply jump threading with a method whose return type is std::pair<int, bool> (actually, any pair of 32-bit values like std::pair<bool, int> and std::pair<int, int>). For example, jump threading does not work for the if statement in func. std::pair<int, bool> callee(int v) {

Hi folks, I couldn't find a specific XOR (OR and AND) optimization on llvm, and therefore I am about to implement it. But first I would like to check with you guys that it really does not exist. For a simple loop like this: nbits = 128; bit_addr = 0; while(nbits--) { bindex=bit_addr>>5; /* Index is number /32 */ bitnumb=bit_addr % 32; /* Bit number in longword */

Hi Daniel, > Hi folks, > > I couldn't find a specific XOR (OR and AND) optimization on llvm, and > therefore I am about to implement it. > But first I would like to check with you guys that it really does not exist. > > For a simple loop like this: > > nbits = 128; > bit_addr = 0; > while(nbits--) > { > bindex=bit_addr>>5; /* Index is

Hi Duncan, when I run "opt -std-compile-opts" on the original source code it has the same output of O3. when I run "opt -std-compile-opts" on the -O3 optimized code, things get even more weird, it outputs the following code: while.body: ; preds = %while.body, %entry %indvar = phi i32 [ 0, %entry ], [ %indvar.next.3, %while.body ] %tmp

Hi, On Tue, Jul 26, 2011 at 11:32 AM, Matt Johnson <johnso87 at crhc.illinois.edu>wrote: > Hi Daniel, > > > Hi folks, > > > > I couldn't find a specific XOR (OR and AND) optimization on llvm, and > > therefore I am about to implement it. > > But first I would like to check with you guys that it really does not > exist. > > > > For a

Hi Vivek, You could work around this by creating a custom ISD node, e.g. MyTargetISD::MyLSHR, with the same type as the general ISD::LSHR. This custom node will then be ignored by the generic DAGCombiner. Convert ISD::LSHR to MyTargetISD::MyLSHR in DAGCombine, optimise it as you see fit, convert it back or lower it directly. I've done this for ISD::CONCAT_VECTORS to avoid an inconvenient

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

Hi all, I have been looking at the way LLVM optimizes code before forwarding it to the backend I develop for my company and while building define i32 @test_extract_subreg_func(i32 %x, i32 %y) #0 { entry: %conv = zext i32 %x to i64 %conv1 = zext i32 %y to i64 %mul = mul nuw i64 %conv1, %conv %shr = lshr i64 %mul, 32 %xor = xor i64 %shr, %mul %conv2 = trunc i64 %xor to i32

Hi everyone, I started digging into MemDep to enhance devirtualization and I found out that it doesn't handle invariant.group if it will find GEP 0, 0. If I understand it correctly getelementptr with zeros is just bitcast. Is there any good reason why it is not canonicalized into bitcast? Example: define void @_Z5testGv() local_unnamed_addr #0 { entry: * %a* = alloca %struct.A, align 8

After a few more tests, I found out that if we set -unroll-threshold to a value large enough, and run "opt -std-compile-opts" or "opt -O3" 3 times, the unroll will be able to unroll the original loop 32 times, and when you have it unrolled for at least 32 times a optimization is triggered, folding it to a single "%xor.3.3.1 = xor i32 %tmp6, -1" (dont know why it does

> On 2015-May-15, at 13:15, Teresa Johnson <tejohnson at google.com> wrote: > > What isn't clear to me is what all uses the available > externally linkage type currently - do you happen to know? It's used for the `inline` keyword in the C language. If you do a `git grep available_externally -- test/` inside a clang checkout you might find some other uses. $ cat