similar to: [LLVMdev] InstCombine "pessimizes" trunc i8 to i1?

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

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*

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. Reid On Wed, Dec 28, 2011 at 6:45 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de>wrote: > > >> Hi! >

> By the way i8 and trunc come from clang as clang represents a bool as i8  > in memory. of course it would > be a nice feature if I could tell clang to always use i1 for bool, this > would also remove the problem. > Is this possible? > > -Jochen #include <stdbool.h> ?

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

Hi, I think this is probably easiest to explain with code (I only provided the essentials for clarity): // begin file jit.cpp int myglobal; void printMyGlobal() { printf("myglobal: %d\n", myglobal); } int main(int argc, char *argv[]) { // This file, jit.cpp has been compiled to bitcode (clang -S -emit-llvm jit.cpp) // and is read into Module M here Module *M = ...

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

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

I have the following simplified llvm ir, which basically returns value based on the first value of a constant array. ---- ; ModuleID = 'simple_ir3.txt' @f.b = constant [1 x i32] [i32 1], align 4 ; constant array with value 1 at the first element define void @f(i32* nocapture %l0) { entry: %fc_ = alloca [1 x i32] %f.b.v = load [1 x i32]* @f.b store [1 x i32] %f.b.v, [1 x

Hi, Comments inline. Ben On 12/08/2008 03:14, "Owen Anderson" <resistor at mac.com> wrote: >> We would like to develop a code generator using LLVM for a target language >> that does not support conditional branches and in fact only supports >> structured control flow, eg. If and while. What's the difference between an "if" and a conditional

I came in to an email this morning that said basically the same thing for the reduced example we were looking at. However, the original IR it came from (before hand reduction) had the data layout set correctly, so there's probably still *something* going on. It's just not what I thought at first. :) Philip On 09/10/2014 02:26 AM, Roel Jordans wrote: > Looking at the -debug

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 Andrew, Thank you for the suggestion. I've looked at CodeGenPrepare.cpp and MoveExtToFormExtLoad() is never run. I also notice that the ARM target produces the same additional register usage (copy) and zero extending (of the copy). (See the usage of r3 &r5 and also r12 & r4 in attached file arm-strcspn.s, my understanding is that 'ldrb' is zero extending.) Here is a

On Aug 12, 2008, at 2:39 AM, Benedict Gaster wrote: > [bg] Consider the LLVM code: > > define i32 @foo(i32 %x, i32 %y) { > entry: > %tobool = icmp eq i32 %x, 0 ; <i1> [#uses=1] > br i1 %tobool, label %ifelse, label %ifthen > > ifthen: ; preds = %entry > %add = add i32 %x, 10 ; <i32> [#uses=1] > ret i32 %add > >

Hi, I have a question about how llvm MemorySSA works, as seems I misunderstand something. Consider following code snippet and corresponding IR with MemorySSA annotations (got with opt -print-memoryssa) void foo(int* b) { int a = 0; int d = 12; if (b) { a = 42; d = 32; } int c = a; int e = d; } ; Function Attrs: noinline nounwind optnone uwtable

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

On 01/28/2015 07:02 AM, Sean Silva wrote: > Could you maybe provide an example where replacing `%always_poison` > with `undef` will change the meaning? At least for me, the thing that > I'm most unclear about is how poison differs from undef. I will second this request for much the same reason. > > -- Sean Silva > > On Wed, Jan 28, 2015 at 2:50 AM, David Majnemer >

Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are clobbering EFLAGS on x86_64. This is inconvenient when the status of bit 9 (IF), which controls interrupts, changes. Here's a simple test program. Assume that the external function foo() modifies the IF bit in EFLAGS. --- #include <stdlib.h> #include <stdbool.h> void foo(void); int a; int bar(void)

Dear all, I have been working on a new LLVM backend. Some instructions, like sub, can take an positive constante, encoded into 5 bits thus lower than 32, and a register, as operands. Unfortunately, DAGCombiner.cpp changes patterns like 'sub x, 5' into 'add x,-5'. Similarly, I found changes in some IR to IR passes, with no clear gain (at least not clear to me), and even penalty

I've developed a working back-end for a custom architecture, based on LLVM 2.6. I'm now trying to cover more of the unique features of this architecture. To make use of one such feature, I'm trying something cunning/crazy with the stack - implementing it in a type of memory that can only be addressed via immediates. I've got this mostly working. However, I came across a problem