similar to: [LLVMdev] -instcombine introduces "undef" values to the IR.

Thanks a lot for the clarification! So if my input .ll is not expected to contain any of the above mentioned weird corner cases, but, after -instcombine, ends up containing "undef" values, then it must be that the input .ll has bugs unknown to me, right? Best Regards, Paul On Wed, Jun 11, 2014 at 3:09 PM, Nick Lewycky <nlewycky at google.com> wrote: > On 11 June 2014 12:26,

I see instcombine doing something I'm not sure is right. Incoming, I have this: %r29 = ptrtoint [71 x i64]* %"t$3" to i64 ; <i64> [#uses=1] %r30 = inttoptr i64 %r29 to i64* ; <i64*> [#uses=1] store i64 72057594037927936, i64* %r30, align 8 Outgoing, I have this: %r30 = getelementptr [71 x i64]* %"t$3", i32 0, i32 0 ; <i64*> [#uses=1] store i64

Sanjoy, You have changed the subject. We still need real world examples showing how taking advantage of “undef” results in beneficial optimization. My belief is that they don’t exist, my reasoning is this: real world programmers are likely to run UBSan before compiling (or if they don’t they should), therefore it is highly unlikely that any “undef” will actually exist during

On Tue, Nov 30, 2010 at 2:48 PM, Jonas Paulsson <jnspaulsson at hotmail.com> wrote: > all right, no fixed point type in LLVM :-( > > May I ask then, what could one expect from various optimizations when using > intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? You'd have to implement explicit support for the new intrinsics in various places. For

Sanjay, I'm looking at some missed optimizations caused by D70246. Here's a test case: define <4 x float> @f(i32 %t32, <4 x float>* %t24) { .entry: %t43 = insertelement <3 x i32> undef, i32 %t32, i32 2 %t44 = bitcast <3 x i32> %t43 to <3 x float> %t45 = shufflevector <3 x float> %t44, <3 x float> undef, <4 x i32> <i32 0, i32 undef,

Hi John, John McCall wrote: >>> Well, we could say non-nsw add and mul are actually "bitwise" operations, so "mul i32 poison, 2" is guaranteed to have its bottom bit zero (but "mul nsw i32 poison, 2" is poison). Of course, there's a limit to how far we can go in that direction, or we just end up with the old notion of undef. Off the top of my head,

Hello, this mail is to raise awareness of https://reviews.llvm.org/D81728, which is substantial enough of a conceptual change that it should probably at least be mentioned in llvm-dev. InstCombine has dealt with target-specific intrinsics for a long time, since its fix-point iteration is arguably the right place to do so. A downside is that there's a pull to add an increasing amount of code

> If we don't care about trying to optimize out overflow checks in > InstCombine, I'd go with moving the complexity to CGP. I think instcombine should optimize out overflow checks (as it does today) without introducing _with_overflow calls. Are there reasons why such an approach would not work? > However, I think > InstCombine is doing the right thing here by forming these.

Hi, In llvm/test/Transforms/InstCombine/cast.ll there is a test like this: target datalayout = "E-p:64:64:64-p1:32:32:32-p2:64:64:64-p3:64:64:64- a0:0:8-f32:32:32-f64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64- v64:64:64-v128:128:128-n8:16:32:64" [...] define <3 x i32> @test60(<4 x i32> %call4) { ; CHECK-LABEL: @test60( ; CHECK-NEXT: [[P10:%.*]] = shufflevector

On Fri, Apr 14, 2017 at 2:19 PM, Mikulin, Dmitry <dmitry.mikulin at sony.com> wrote: > >>> Is this a run with debug info? i.e. are you passing -g to the per-TU >>> pipeline? I'm inclined to think this is mostly an additive effect >>> adding matchers here and there that don't really hurt small testcases >>> but we pay the debt over time (in

> 1. hi*8 -> hi << 3 > > 2. ((idx >> 3) << 3) -> idx & -8 > > 3. hi*8+lo -> hi*8 | lo > > 4. (idx & -8) | (idx & 7) -> idx & (-8 | 7) -> idx > > > > After 155362 pattern #2 is deferred to DAGCombine stage, so InstCombine is > unable to apply pattern #4: > > 4*. ((idx >>

Hello, Can the Instcombine pass increase the number of instructions of a block? -- *Rafael Parizi* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120626/53a8661d/attachment.html>

Hi! before InstCombine (llvm::createInstructionCombiningPass()) I have a trunc from i8 to i1 and then a select: %45 = load i8* @myGlobal, align 1 %tobool = trunc i8 %45 to i1 %cond = select i1 %tobool, float 1.000000e+00, float -1.000000e+00 after instCombine I have: %29 = load i8* @myGlobal, align 1 %30 = and i8 %29, 1 %tobool = icmp ne i8 %30, 0 %cond = select i1 %tobool, float 1.000000e+00,

On 11 Sep 2017, at 21:32, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As a data point for this, I did a quick walkthrough of the top-level of instcombine, and one thing that stuck out to me is that it tries to sink instructions in certain "easy" scenarios. That doesn't fit a graph rewriting system. The sinking in instcombine is not always a win. We

Just thinking out loud…. I’m really not familiar with the vast majority of what instcombine does, so please excuse me if my naiveté is too obvious. I can’t help but notice all of the uses of ‘and’ in Daniel B’s description of what instcombine is right now: > On Sep 8, 2017, at 11:27 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > FWIW, Before getting to

> On Apr 13, 2017, at 7:43 PM, Davide Italiano <davide at freebsd.org> wrote: > > On Thu, Apr 13, 2017 at 5:18 PM, Mikulin, Dmitry > <dmitry.mikulin at sony.com> wrote: >> I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M.

The fact two IR values are defined the same way doesn't necessarily imply they are actually the same value. e.g. %a = load volatile i32, i32* %p %b = load volatile i32, i32* %p As Sanjoy said, though, it should always be legal to optimize all uses of different "freeze(%x)" values to use the same def - this is equivalent to choosing the same value for all freezes. It's just not

Hi Jakob, I've a problem related to the commit #155362. Consider the following snippet: void bar(float* f) { ... } void foo(float* f, int idx) { int hi = idx>>3; int lo = idx&7; bar(&f[hi*8+lo]); // hi*8 + lo == idx bar(&f[hi*10+lo]); } Before 155362 revision InstCombine was able to optimize hi*8+lo to idx by applying following patterns: 1. hi*8 -> hi << 3

It appears that this behaviour of InstCombine is at least somewhat intended, as there are several tests that fail after the change mentioned before: cast.ll, gep-addrspace.ll and getelementptr.ll in test/Transforms/InstCombine. I feel a little uncomfortable applying the patch after knowing this, and removing those tests doesn't seem like a great solution. What are your thoughts? For now, I

Hi, I have some WIP that leverages @llvm.assume in some optimization passes other than InstCombine. However, it doesn't work yet because InstCombine removes @llvm.assume calls that are useful for later optimizations. For example, given define i32 @foo(i32 %a, i32 %b) { %sum = add i32 %a, %b %1 = icmp sge i32 %sum, 0 call void @llvm.assume(i1 %1) ret i32 %sum } "opt