similar to: [LLVMdev] Machine Dependence of Liveness Analysis

Hi Y'all, Could someone explain to me why liveness-analysis is target dependent? In particular, what is an example of a set of llvm instructions, that would have different liveness properties (in llvm terms), depending on the target architecture? This is inspired by the following post: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-January/037428.html Thanks ~Dimo -------------- next part

> The underlying liveness datastructure is a list of ranges where each vreg is alive > (ranges in terms of instructions numbered). I remember a couple of later linear scan > papers describing the same thing (Traub et.al. being the first if I remember correctly). > That should be as accurate as you can get in terms of liveness information. It depends on the details. For example, given

Jin-Gu Thanks for your suggestion. Using liveness information for virtual register is a good idea, but what I am working on is a source-to-source compiler, so I prefer to use FunctionPass instead of MachineFunctionPass. Interestingly I found a FunctionPass example for classic liveness data flow equation. http://cs.pub.ro/~cpl/wiki/images/1/15/Hello.txt

The isKill must be correct if present, but a vreg may still be killed even if the operand has no Kill flag. The isDead and isUndef flags however are required to be correct. We need further details to say anything about your problem, a LiveIntervals::dump() dump for example would be helpful to assess whether the liveness data is correct in your case. - Matthias > On Jul 28, 2016, at 1:42 PM,

On 7/28/2016 3:37 PM, Xiaochu Liu via llvm-dev wrote: > > I am trying to use liveness of a variable while writing a > machinefunction pass. But it seems that some virtual registers are not > marked as dead while they should be (never used by anything else). I get > those info by callings isDead or isDef function for that MachineOperand > (vreg). Is there a way to get more

K2Fb4jFc4`eOyWeV|~]!5P")k:JgiZ k;tj2X.Hs!Yg`Qo{dDRqqOKEcE <J:DiMo]9g#"rw;);UY*8GayoN$r?g8Paxn0tb:wL' ~Nl^n7x%^ $`xi_oK?K&-[1vOWe 8xiXiR* i`C9{Xj]W_i^s!'zs( 0G ByNw,pHf&;_kb-`:c _QRG):P.7qIgan[[M-S vCXV)C UdepZlk2Bk(|-DD'}O[^*} Ru\~- hraw~**p'4nMnG3[Is1 g3dh!s t# Ca $z&)KCb`_:# ZT QwYBj"aTB/)/g;_zGjd8bsP u;\;fxMHe#/A"Cg

> On May 24, 2016, at 11:01 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > > Enabling subreg liveness tracking didn't do anything. By altering the allocation order I managed to get the backend to use CL/CH for the struct, but the stores were still separate (even though storing CX would be correct)... > > Here's another question that falls into the

Hi, I may have a use-case for IR liveness analysis, although it's in the context of debuginfo. Using the sample code from this bug report [0], which is a fairly trivial loop: int foo(int count) { int result = 0; for (unsigned long long ix = start; ix != count; ++ix) result += external(ix); return result; } On x86_64 the 32-bit "count" comparison

Dear there, I am trying to use liveness of a variable while writing a machinefunction pass. But it seems that some virtual registers are not marked as dead while they should be (never used by anything else). I get those info by callings isDead or isDef function for that MachineOperand (vreg). Is there a way to get more accurate liveness info? Thanks, Xiaochu -------------- next part

Hello all Currently I want to use the accurate liveness information when writing a *target independent* FunctionPass based on LLVM. The one I can find is LiveValues, a FunctionPass. But it doesn't use classic dataflow equation and can only provide approximate and conservative result. The another one is LiveVariables which use classic data flow equation, but it comes from Clang's analysis

Hi, I wonder if it would be possible to extend foldMemoryOperandImp() so that targets can check for liveness of a particular phys reg? The case I am thinking of is when the new instruction clobbers the CC reg, while the old one did not. In this case the new instruction can only become a replacement if the CC reg is known to be dead. The idea is that liveness of phys regs should be available

All, ARM LLVM afficianados: I'm trying to understand how LiveVariables computes liveness for CPSR. In particular, I would like to tell whether a particular instruction is a use/kill/def for doing some within block liveness checking I need. Thanks in advance, David -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi list. I'm trying to enable sub-register liveness tracking for our target but I'm hitting the following assert on VirtRegRewriter::readsUndefSubreg: assert(SubRegIdx != 0 && LI.hasSubRanges()); The reason is that I have a register class of two bit predicates where only the low bit is allocatable so there's only a single sub-register. Now, MachineRegisterInfo only enables

Hi all, Sorry to bother those not interested in this problem. I have a problem while I want to reuse the liveness information after register allocation. When I use the livein_begin() from MachineBasicBlock to get the live-in registers after register alloction. I found that the liveness information is sometime incorrect. For example, some registers should be live-in to the machine basic block as

Arnold, Interesting point. This fake use would also need to be probably marked as isUndef(), but I could not foresee all possible corner cases from that. Could it be overly conservative? Would I lose the ability of some sort "predicate value propagation" that I seem to gain from introduction of an explicit flag? Can someone comment? Thanks. Sergei -- Qualcomm Innovation Center,

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 use case to prove my point. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. >

I would expect that it shouldn't be too hard to pass around a reference to LiveIntervalAnalysis*. Patches welcome :) - Matthias > On Apr 27, 2016, at 11:38 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ping. > > Either this can be implemented easily, or the current SystemZ optimization LAY -> AGSI in foldMemoryOperandImpl() should be

Note that this only works for targets that say TargetRegisterInfo::trackLivenessAfterRegAlloc()== true. > On Feb 16, 2017, at 1:21 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Anitha, > > The liveness information is usually dropped after regalloc. > Therefore the short answer is no, this information is not available before producing

I've been working on patches to improve subregister liveness tracking on llvm and I wanted to inform the llvm community about the overal design/motivation for them. I will send the patches to llvm-commits later today. Greetings Matthias Braun Subregisters in llvm ==================== Some targets can access registers in different ways resulting in wider or narrower accesses. For

The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.