similar to: [LLVMdev] Pass to simplify struct select?

I've attached the module->dump() that our code is producing. Unfortunately this is the smallest test case I have available. This is before any optimization passes are applied. There are two separate modules in existence at the time, and there are no guarantees about the order the surrounding code calls those functions, so there may be some interaction between them? There shouldn't

I'm writing a front end for an existing interpreted language with slightly odd semantics for primitive values. Similar to the values in a database table, any value could be null, even for non-pointer types. For example a boolean variable could be true, false, or null. To model this behaviour, I'm passing an {i1, [type]} around for every numeric type. And using insertvalue / extractvalue

Hi all, I've been implementing some stuff that uses the new structs-as-firstclass values code. Apart from some implementation problems, I'm spotting a few structural problems that seem non-trivial to fix. In particular, now that structs are a first class values, the old way or returning multiple values is a bit confusing. The old way had a variable number of arguments to the return

The scoreboard hazard detector that I've added for the PPC 440 is not detecting hazards as it should (which certainly could be my fault somehow, but...). For example, it will produce a schedule that looks like... SU(28): 0x127969b0: f64,ch = LFD 0x12793aa0, 0x1277b4f0, 0x127965b0<Mem:LD8[%scevgep100](tbaa=!"double")> [ORD=41] [ID=28] SU(46): 0x12796ab0: f64 = FADD 0x127969b0,

Hi, I have a question about the IR model for SEH filters (as I want to use the same model for CLR filters). In particular, when an outer filter is invoked before entering an inner finally, which piece of IR reflects the filter's side-effects? To take a concrete example, consider this C code: void foo() { int x; __try { x = 0; __try { x = 2; may_throw(); }

Something like this should work I think. ; ModuleID = 'test.ll' source_filename = "test.ll" define void @entry(<4 x i32>* %a, <4 x i32>* %b, <4 x i32>* %x) { Entry: %tmp = load <4 x i32>, <4 x i32>* %a, align 16 %tmp1 = load <4 x i32>, <4 x i32>* %b, align 16 %tmp2 = add <4 x i32> %tmp, %tmp1 %tmpsign = icmp slt <4 x

This is indeed a bug. I get a different error on my machine. Until we solve this bug, as a workaround, you can use the <4 x float> type for which the vselect works. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Fan Dawei Sent: Wednesday, October 19, 2011 10:10 To: LLVMdev at cs.uiuc.edu Subject: [LLVMdev] Error when cond of select instruction is

Hi LLVMdev, In the specification of llvm ir, the select operation can takes a condition of vector type, 'select' Instruction Syntax: <result> = select *selty* <cond>, <ty> <val1>, <ty> <val2> *; yields ty* *selty* is either i1 or {<N x i1>} Overview: The 'select' instruction is used to choose one value based on a condition,

Hi Rotem, What do you mean by "you can use the <4 x float> type for which the vselect works". Do you mean that then back-end can correctly split the operands when it is a four elements vector? I've try that, but it still fails. On Wed, Oct 19, 2011 at 4:21 PM, Rotem, Nadav <nadav.rotem at intel.com> wrote: > This is indeed a bug. I get a different error on my

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some

On Apr 8, 2012, at 8:47 AM, Paul J. Lucas wrote: > On Apr 8, 2012, at 4:20 AM, Bill Wendling wrote: > >> On Apr 4, 2012, at 9:32 PM, Paul J. Lucas wrote: >> >>> This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are

While playing with SLPVectorizer, I notice that it will happily vectorize cases involving extractelement/insertelement, but won't vectorize isomorphic cases involving extractvalue/insertvalue (such as the attached example). Is that something that could be straightforward to add to SLPVectorizer, or are there some hard issue? In particular, the transformation would seem to require casts of

---------- Forwarded message ---------- From: charles quarra <charllsnotieneningunputocorreo at gmail.com> Date: 2012/12/13 Subject: error while linking modules with exception handling demo code To: llvmdev at cs.uiuc.edu Hi, I am building a module X with an arithmetic function foo, a module Y with an arithmetic function foo2 that invokes foo. For the invocation be a proper one (being

Are you able to send any IR for others to reproduce this issue? On Wed, Jul 17, 2013 at 11:23 PM, Peter Newman <peter at uformia.com> wrote: > Unfortunately, this doesn't appear to be the bug I'm hitting. I applied > the fix to my source and it didn't make a difference. > > Also further testing found me getting the same behavior with other SIMD > instructions.

Unfortunately, this doesn't appear to be the bug I'm hitting. I applied the fix to my source and it didn't make a difference. Also further testing found me getting the same behavior with other SIMD instructions. The common factor is in each case, ECX is set to 0x7fffffff, and it's an operation using xmm ptr ecx+offset . Additionally, turning the optimization level passed to

On Sep 29, 2010, at 8:35 AMPDT, Ralf Karrenberg wrote: > Hello everybody, > > I have stumbled upon a test case (the attached module is a slightly > reduced version) that shows extremely reduced performance on linux > compared to windows when executed using LLVM's JIT. > > We narrowed the problem down to the actual code being generated, the > source IR on both systems

Hi Shuxin I think i might have written that test. And yeah, no matter what values you get you’ll get a 0.0. Its probably a bad test case, but i can’t remember if it exposed a bug in this form or not. Since writing it Chandler rewrote SROA anyway so the original bug is long gone. Thanks, Pete On Apr 5, 2013, at 11:57 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, > >

Hi, I found a mysterious behavior of LLVM optimizer. I compiled the following code by clang -emit-llvm -S: #include <stddef.h> static const struct t {char t[4]; char s;} p = {{}, 'a'}; char f() { return ((char*)&p)[offsetof(struct t, s)]; } then I obtained the following LLVM IR: %struct.t = type { [4 x i8], i8 } @p = constant %struct.t { [4 x i8] zeroinitializer, i8 97

Hi, Following is excerpted from dynamic-vector-gep.ll. The resulting "extractelement" seems to always return 0.0f regardless the value idx1 and idx2 is holding. Am I missing something here or there is something fishy take place? Thanks Shuxin 101 ; CHECK: test6 102 ; CHECK: insertelement <4 x float> zeroinitializer, float 1.000000e+00, i32 %idx1 103 ; CHECK:

I just upgraded our optimizer to LLVM 3.0 from 2.8 and noticed that the scalar replacement of aggregates pass takes a lot longer for some code. Has there been a performance regression in this pass, or does it do more work? LLVM 3.0: Total Execution Time: 1.0600 seconds (1.0526 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.5100