similar to: opt -instcombine interesting behavior

> On Dec 19, 2016, at 9:51 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> %reg = alloca i32, i32 0 > Allocating 0 bytes is legal but it's an undefined behavior, please refer: > http://llvm.org/docs/LangRef.html#id184 <http://llvm.org/docs/LangRef.html#id184> Nit: I believe that when LangRef says “the result is undefined”, it does not

> %reg = alloca i32, i32 0 Allocating 0 bytes is legal but it's an undefined behavior, please refer: http://llvm.org/docs/LangRef.html#id184 You need to correct allocation to get the desired output, i.e.: > %reg = alloca i32, i32 1 Regards, Ashutosh > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Stephan Plöger via

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

Hi Fellows, If a .ll file contains no "undef"'s, does it necessarily mean that every value is properly initialized before use in the IR? What confuses me is that I notice that -instcombine can introduce "undef" to the previously undef-clean .ll file ... is it always safe to use -instcombine as one of the preprocessing pass? Thanks. Best, Paul -------------- next

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,

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>

I perform the Instcombine pass over Rijndael benchmark from Mibench ( suite of benchmarks). For compile, I use "-Instcount" for counting the instructions. Comparing the bench without transformation with the bench transformed by instcombine, I perceived a 10% of increase in the number of instructions. This is possible? On Wed, Jun 27, 2012 at 4:57 AM, Duncan Sands <baldrick at

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

Fixes build of bugpoint, llvm-ld and opt. OK for commit? --- CMakeLists.txt | 1 + tools/bugpoint/CMakeLists.txt | 2 +- tools/llvm-ld/CMakeLists.txt | 2 +- tools/opt/CMakeLists.txt | 2 +- 4 files changed, 4 insertions(+), 3 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 9bce039..0edd509 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@

On Dec 27, 2011, at 5:09 AM, Jochen Wilhelmy wrote: > 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*

Hi Rafael, > Can the Instcombine pass increase the number of instructions of a block? while it usually doesn't, in theory it can increase the number of LLVM IR instructions. I don't recall an example off the top of my head, but the usual situation is that replacing some instruction I with a pair J, K results in better code generation. There are a small number of cases like this.

On Fri, 4 Apr 2008, David Greene wrote: > I am confused by this bit of code in instcombine: > > 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { > 09790 const Value *GEPI0 = GEPI->getOperand(0); > 09791 // TODO: Consider a target hook for valid address spaces for this > xform. > 09792 if (isa<ConstantPointerNull>(GEPI0)

> 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.

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

On Friday 04 April 2008 13:42, David Greene wrote: > On Friday 04 April 2008 13:07, Chris Lattner wrote: > > > So how does the undef store to null appear in the IR when it isn't > > > attached anywhere and how can I get rid of it? > > > > Don't do undefined behavior? :) > > I don't think it's undefined behavior. Right before instcombine, we

I found this with LLVM 2.3 and reproduced with svn as of about thirty minutes ago and they both fail in the same way. If you run this code through opt -instcombine define fastcc i64 @fibo(i64) { switch i64 %0, label %2 [ i64 0, label %8 i64 1, label %8 ] ; <label>:2 ; preds = %1 %3 = sub i64 %0, 1 ; <i64> [#uses=1] %4 = call i64 @fibo(i64 %3) ; <i64> [#uses=1] %5 =

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

On Friday 04 April 2008 13:07, Chris Lattner wrote: > > So how does the undef store to null appear in the IR when it isn't > > attached anywhere and how can I get rid of it? > > Don't do undefined behavior? :) I don't think it's undefined behavior. Right before instcombine, we have this: %r60 = load <2 x i64>* %"$LCS_1", align 16 ; <<2

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

Am 29.12.2011 19:52, schrieb Reid Kleckner: > I think Chris is saying that the and is necessary because with your i1 > trunc you're ignoring all of the high bits. The and implements that. > If you don't want this behavior, don't generate the trunc in the > first place and just compare the full width to zero. But if a backend sees trunc from i8 to i1 it should know