similar to: Missing kill flag on Machine Instruction operands

On Jul 14, 2009, at 12:10 PM, Jakob Stoklund Olesen wrote: > Hi, > > Two-address instructions are represented as normal three-address > instructions with a Desc bit that indicates the first two operands are > tied together. The question is, should the second operand have a > <kill> flag? > > a: %R0<def> = MUL %R0, %R1<kill> > b: %R0<def> = MUL

Hi, Two-address instructions are represented as normal three-address instructions with a Desc bit that indicates the first two operands are tied together. The question is, should the second operand have a <kill> flag? a: %R0<def> = MUL %R0, %R1<kill> b: %R0<def> = MUL %R0<kill>, %R1<kill> I think the current policy is a: There should be no kill-flag.

On Thursday 17 January 2008 13:03, Evan Cheng wrote: > > So why does the live range extend throughout the entire basic block? > > > > %reg1055 doesn't appear anywhere else in the program so it shouldn't > > be > > live-in to the block. > > It could be a bug. Can you get me a test case? I'll see if I can whittle it down. It's a pretty huge

On Jan 16, 2008, at 11:49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill>

I had been assuming that give a LiveRange a, a.valno->def, if valid, would be the same as a.start. But this is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr

Andy, Jacob, I have ported Hexagon MI scheduler to use the new scheduler infrastructure, but one of my tests triggers an assert in LiveInterval update. On the surface it does not make much sense to me, so I wonder if this is something you readily recognize, before I try to prop it open... The assert is: lib/CodeGen/LiveInterval.cpp:266: llvm::LiveRange*

On Aug 13, 2012, at 8:34 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, > > Yes, this is what Arnold has suggested also, and from this point it looks > like it should work, but it will require parsing the bundle every time we > care to know whether this is a real use or a conditional def. This might > become awkward... but I guess I should provide a better

Thanks Matthias I can also use the method intervalIsInOneMBB() from LiveIntervals class to relate a LiveInterval to a MachineBasicBlock, right? Em 04/09/2015 2:26 PM, "Matthias Braun" <mbraun at apple.com> escreveu: > There is no direct support for this, but you can use > LiveIntervalAnalysis::getMBBStartIndex()/getMBBEndIndex()/getMBBFromIndex() > to relate the

In r226336 I shove off 1.2 seconds out of 9.8 seconds for lld to link lld. That's done by parallelizing archive member parsing. But I realized that was not the slowest pass. The single slowest pass in LLD is LayoutPass. Only sort() at the last of Layoutpass::perform takes about 3 seconds (one third of total execution time). It is because the comparison function passed to sort, compareAtoms,

Spiller::Spill( LiveInterval *li, SmallVectorImpl<LiveInterval*> &newIntervals, const SmallVectorImpl<LiveInterval*> &spillIs ); has two reference vectors which contain a small list of Live Intervals. What is the register allocator's job to do with these intervals other than analysis. What more needed other than to know

Hi, I'm working on the implementation of Extended Linear Scan register allocator as described by Sarkar & Bodik. One of the interesting features of their algorithm is the possibility to allocate different physical registers to different live-ranges of the same LiveInterval. Of course, it may require some glue code to be inserted in cases, where different physical regs were assigned to

Hi, I insert a new machine basic block(MBB) before Greedy Register Allocation, after Simple Register Coalescing. But I encounter a fatal error "regalloc = ... not currently supported with -O0". I use command line with opt level O2, not O0. The probable reason of this error is that no LiveInterval information for newly MBB which is used by Register Allocation. And, LiveIntervals depend

Hi, I am using mcjit in llvm 3.6 to jit kernels to x86 avx2. I've noticed some inefficient use of the stack around constant vectors. In one example, I have code that computes a series of constant vectors at compile time. Each vector has a single use. In the final asm, I see a series of spills at the top of the function of all the constant vectors immediately to stack, then each use references

Hi, In PR2193 LiveVariables runs out of memory on a 512M limit, after processing 11557 basicblocks. VirtRegInfo has ~180000 entries with ~700 bytes each. If I give it more memory (1.5G) it runs out of memory in LiveInterval. I don't see any easy solution to reduce memory usage, but should we optimize such a huge function at once? If the function is over some reasonable limit (5k

Hello to all. I'm trying to implement a simple register allocator using graph colouring (I know, everyone has already done that :-)) and I'm also using LLVM 3.4 from master branch. The algorithm I'm using is based on the one described on the "Modern Compiler Implementation in C". My implementation is totally experimental and doesn't aim to be fast, eficient or even

Hi, I got that message from a call to InstrEmitter::AddOperand. I am writing a back end for CortexM0 (for self teaching purposes), I am working on LDR with immediate offset instruction. In the ARM backend, if the offset is 0, the following code is executed by the function ARMDAGToDAGISel::SelectThumbAddrModeImm5S Base = N.getOperand(0); OffImm = CurDAG->getTargetConstant(0, MVT::i32);

Hi, I’m hitting a machine verifier error in a trivial testcase which I don’t understand. There are 2 dead defs of the same register: --- name: multiple_connected_compnents_dead tracksRegLiveness: true body: | bb.0: dead %0:vgpr_32 = V_MOV_B32_e32 0, implicit $exec dead %0:vgpr_32 = V_MOV_B32_e32 1, implicit $exec ... The live intervals look OK to me with 1 valno

Hello to all LLVM Developers. Given a object from a LiveInterval class, is there any way to know if this Live Interval is part or is inside a loop? Att -- Natanael Ramos Membro do corpo discente de Ciência da Computação pelo Instituto Federal de Minas Gerais - Campus Formiga -------------- next part -------------- An HTML attachment was scrubbed... URL:

I have used the following command for my pass (without -mem2reg): clang -Xclang -load -Xclang MYPASS.so -c ../../tests/test1.c For mem2reg, I tried the following: clang -mllvm -mem2reg -Xclang -load -Xclang MYPASS.so -c ../../tests/test1.c On Mon, Mar 21, 2016 at 9:26 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Mar 21, 2016, at 6:23 PM, Syed Rafiul Hussain

On Feb 27, 2009, at 7:20 AM, Roman Levenstein wrote: > Hi, > > I'm working on the implementation of Extended Linear Scan register > allocator as described by Sarkar & Bodik. > One of the interesting features of their algorithm is the possibility > to allocate different physical registers to different live-ranges of > the same LiveInterval. Of course, it may require