similar to: [LLVMdev] liveness assertion problem in llc

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

Hi, I've been playing around with the APFloat class lately and I came across behavior I was not expecting based on reading the implementation comments and I'm wondering if it's a bug or intentional. The behavior concerns converting an APFloat to a string and back again. In the implementation of ``APFloat::toString(...)`` you can specify ``FormatPrecision`` as 0. The method comments

On Tue, Oct 10, 2017 at 4:48 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 10/9/2017 3:10 AM, Gaël Jobin via llvm-dev wrote: > > Hi all, > > I got a silly bug when compiling our project with the latest Clang. Here's > the outputted assembly: > > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4]

configure.ac | 20 doc/Makefile.am | 2 libswfdec/jpeg/Makefile.am | 28 libswfdec/jpeg/bits.h | 120 --- libswfdec/jpeg/jpeg.c | 1129 +++++++++++++++++++++---------------- libswfdec/jpeg/jpeg.h | 58 + libswfdec/jpeg/jpeg_bits.c | 154 +++++ libswfdec/jpeg/jpeg_bits.h | 32 +

I'm not sure I understand what your problem is, but are you calling the removeRegOperandFromUseList on the machine operand after changing it to GA? You have to call removeRegOperandFromUseList before changing the operand's type, as it expects a register operand. 2015-06-16 10:05 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > @Alex: Thanks. setOffset(0) eliminated any previous

libswfdec/jpeg/Makefile.am | 18 - libswfdec/jpeg/bits.h | 140 ++++++------- libswfdec/jpeg/huffman.c | 67 +++--- libswfdec/jpeg/huffman.h | 35 +-- libswfdec/jpeg/jpeg.c | 217 +++++++------------- libswfdec/jpeg/jpeg.h | 28 +- libswfdec/jpeg/jpeg_debug.h | 25 -- libswfdec/jpeg/jpeg_internal.h | 143

Hi all, I got a silly bug when compiling our project with the latest Clang. Here's the outputted assembly: > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4] > ldr r6, [r4, r6, lsl #2] > bx r6 For the code to execute correctly, either the _ldr_ should be a _ldrne_ instruction or the _ldreq_ instruction should be removed. The error seems to

  Hello, I am trying to clone a machine basic block when I ran into some issues, where I am not able to make some headway. Any of yours help is highly appreciated here: My question is about Machine Basic Block Duplication:   -          Is there a utility to clone a MachineBasicBlock in LLVM? I found utility to clone machineInstrs, but couldn’t find similar utility for MachineBasicBlock. So, I

Is LiveVariables updated correctly when TII->RemoveBranch and TII->InsertBranch are called in the following piece of code? - MachineBasicBlock::updateTerminator() line 307 of MachineBasicBlock.cpp: if (FBB) { // The block has a non-fallthrough conditional branch. If one of its // successors is its layout successor, rewrite it to a fallthrough // conditional branch.

Hi Yang, > bnz R2, LBB0_34 > > I do not have any clue what happens when compiling with -O2. > Can someone make a suggestion? Is the "bnz" instruction marked "isBarrier" in your TableGen files? If so, that would mean LLVM considers fallthrough impossible and decides it can move LBB0_33 around at will. It's still very odd that it thinks it can put it

Adam Jackson (10): Fix build on bigendian Don't include xf86Priv.h s/\<alloc\>/malloc/g Fix bAccessVGAPCIInfo to read when you tell it to Fix for new vgaHW ABI Fall back to shadowfb if XAA is unavailable Fix XGIValidMode for 1.13 API i2c: Don't scream on literally every single write to SCL or SDA ddc: Fix uncredible fail in

I was hoping to get feedback on this proposal formatted as a patch. I'd like to teach AnalyzeBranch to handle conditional returns on PPC, but the currently documented API for AnalyzeBranch doesn't support it. I propose the following enhancement to the API so that I can teach AnalyzeBranch about conditional return instructions. ---------- Forwarded message ---------- From: Kyle Butt

Hi, I think there might be a bug in the tail duplicator (called from MachineBlockPlacement in my case), when duplicating a block that contains an implicit fall-through. Suppose you have the following blocks BB#1: Predecessors according to CFG: BB#2 ... conditional_branch <BB#3> < implicit fall-through to BB#2 > Successors according to CFG: BB#2 BB#3 BB#2:

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

Hello again, I am trying to implement an optimization pass for PowerPC such that simple loops use the special "counter register" (CTR) to track the induction variable. This is helpful because, in addition to reducing register pressure, there is a combined decrement-compare-and-branch instruction BZND (there are also other related instructions). I started this process by converting the

Hey Ryan, You end with a large constant immediate offset value because the register operand stores the register id in a union together with the offset that's used by the global address operand. Just add 'setOffset(0)' to your change method and that should solve your problem. 2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > So I have this for

Hi, What kind of C/C++ high level code can generate a computed jump, such as: jmpq *%r14 or jmpq *(%r14,%rbx,8) ? I imagine that any calls (including virtual) would use something like 'call *%r14', and the above jumps are mostly from 'switch' statements. Is this correct? Anything else? Thank you, Dan

I've ran across an issue in BranchFolding.cpp where it is incorrectly folding a branch to the wrong fallthrough location. This is in LLVM 2.4 and seems to be in 2.5 also. The code in question is: void BranchFolder::OptimizeBlock(MachineBasicBlock *MBB) { MachineFunction::iterator FallThrough = MBB; ++FallThrough; // If this block is empty, make everyone use its fall-through, not

On Jun 14, 2011, at 1:07 AM, Duncan Sands wrote: > Hi Andrew, > >> No. Duncan suggested that he could hitch a ride with us through France. The problem is, we're not driving to Spain at all and there doesn't appear to be any place to transfer. >> >> The point is, you're not going to be able to leverage most of a CFG-based optimizing compiler if don't use

According to the docs, InsertBranch should only be called if AnalyzeBranch returns success. But in targets (like ARM or Sparc) that don't implement them, the following test fails: ----------------------------------- void %__gcov_init() { entry: switch uint 0, label %cond_true.i [ uint 0, label %UnifiedReturnBlock uint 875573313, label