similar to: [LLVMdev] Crash on accessing deleted MBBs (new backend)

Hi Simon, The x86 backend does generate scalar SSE2 instructions. For your example, it should emit something like: .text .align 4 .globl _sum_d _sum_d: subl $12, %esp movl 20(%esp), %eax movl 16(%esp), %ecx cmpl $0, %eax jne LBB_sum_d_2 # cond_true.preheader LBB_sum_d_1: # entry.bb9_crit_edge pxor %xmm0,

Replying to my self here. It seems I was missing an isTerminator = 1 on the branch instruction in question, so LLVM didn't know that the instruction terminated a basic block. Does that make sense, or is just masking some other problem? Thanks, Andreas On 9/28/07, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Hi, > I'm trying to write up my little m68k backend

Yeah, that will cause problems. However, I expect an assertion somewhere. Any chance you can track down the exact problem? Thanks. Evan On Sep 28, 2007, at 1:37 PM, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Replying to my self here. It seems I was missing an isTerminator = 1 > on the branch instruction in question, so LLVM didn't know that the >

Hi, I'm building a little JIT that creates functions to do array manipulations, eg. sum all the elements of a double* array. I'm writing this in python, generating llvm assembly intructions and piping that through a call to ParseAssemblyString, ExecutionEngine, etc. It's working OK on integer values, but i'm getting nasty floating point exceptions when i try this on double*

I guess isUnpredicatedTerminator() and friends would just return false, but maybe there should be an assertion in an earlier pass that all instructions in the tail position of basic blocks really are terminators, or is that not required? // A On 9/29/07, Evan Cheng <evan.cheng at apple.com> wrote: > Yeah, that will cause problems. However, I expect an assertion > somewhere. Any

On Jan 23, 2013, at 12:36 PM, Stefan Hepp <stefan at stefant.org> wrote: > However, an alternative option could be to simply disallow different edge weights for edges with the same source and destination, or to make the call to getEdgeFreq(Pred,BB) in BlockFrequencyImpl distinguish between the edges, which would eliminate the need for an additional PtrSet, but is not that easy to

Hi, On 01/23/2013 11:30 PM, Jakob Stoklund Olesen wrote: > If you can find the place that creates the duplicate MBB edge, that would be great. > Found it :) It happens in lib/CodeGen/IfConversion.cpp at the very end in MergeBlocks. I attached a small patch that should resolve that issue. Our tests now compile sucessfully even without my previous patch. regards, Stefan --------------

On Fri, 2004-07-09 at 05:02, Vladimir Prus wrote: > I've just spend some time looking at the above function, and while I > understood what it does, a comment would have helped a lot. Thanks for bringing this to my attention! > Maybe, something like: > > // Determine the end of the live interval for this register > // For physical register, all internvals are within basic

We are developing a new backend for a custom processor using LLVM. After updating to LLVM 3.2, we run into an assertion in BlockFrequencyImpl.h. The offending test-case looks basically like this: for ( ... ) { switch (i) { case 100: // do something break; case 102: // do something else break; case 103: // do some more break; case 104: // now something different

I've just spend some time looking at the above function, and while I understood what it does, a comment would have helped a lot. Maybe, something like: // Determine the end of the live interval for this register // For physical register, all internvals are within basic blocks so // we look for the instruction in this basic block which last uses it. The first loop might have a comment like: