similar to: Liveness of virtual registers

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

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:49 PM, Matthias Braun wrote: > > The isDead and isUndef flags however are required to be correct. Undef yes, but what relies on isDead being accurate (before live interval computation)? -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

> On Jul 28, 2016, at 1:52 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > > On 7/28/2016 3:49 PM, Matthias Braun wrote: >> >> The isDead and isUndef flags however are required to be correct. > > Undef yes, but what relies on isDead being accurate (before live interval computation)? I only remember Andy/Quentin making those conservative correctness

2015-04-28 10:15 GMT-07:00 Hal Finkel <hfinkel at anl.gov>: > > ------------------------------ > > *From: *"Alex L" <arphaman at gmail.com> > *To: *"LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > *Sent: *Tuesday, April 28, 2015 11:56:42 AM > *Subject: *[LLVMdev] RFC: Machine Level IR text-based serialization format > >

Hi,   For a custom target, there is a pass to perform memory dependence analysis, where, i need to get memory pointer for "load instruction". I want to check the pointer alias behavior. I am getting this by considering the memoperands for the load instruction.   For "load instruction", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0;

Hi, I have ported LLC to a risc cpu. It can pass benchmark that I have at current. But I want do some optimization after register alloction by adjusting register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. R4 is marked <kill> at MBB0. If I scan R4's

On Jan 14, 2010, at 6:39 PM, 任坤 wrote: > But I want do some optimization after register alloction by adjusting > register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. You can also look at RegisterScavenging.cpp and MachineVerifier.cpp. They are doing the same

To get this out first: I'd love to have a way to serialize machine-IR! I often spend a lot of time trying to create .ll files in a way that the machine-IR still looks a certain way when it finally hits the relevant passes in codegen. It would be so much easier to just specify the machine IR immediately before the pass I'm interested in. For that use case it is worth keeping the following

Thanks. I saw the header comments but it wasn’t clear to me what the difference between those concepts is? My slightly vague understanding is IsDef means that the register specified by this operand is set by the machine instruction. So I understand that to mean the MO will override that register? Also things like early clobber, perhaps there is another document that clarifies some of these

Hi Quentin, On 08/15/14 19:01, Quentin Colombet wrote: [...] >> The question is: How should true subregister definitions be >> expressed so that they do not interfere with each other? See the >> detailed problem description below. > > We do have a limitation in our current liveness tracking for > sub-register. Therefore, I am not sure that is possible. > >

Jakob and anyone else who might be interested... Base on this patch back in August, I sense some need to double check with you whether it is OK to start making a heavy use of MachineOperand TargetFlags? We do seem to have a compelling reason for it in Hexagon, and I wanted to make sure that it is OK with everyone. I plan to use it for attributing target specific info to MOs and in more general

> On Jul 28, 2016, at 2:01 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Jul 28, 2016, at 1:52 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> On 7/28/2016 3:49 PM, Matthias Braun wrote: >>> >>> The isDead and isUndef flags however are required to be correct. >> >> Undef yes,

Is there anything that documents what these properties (and the other similar properties) do on the MachineOperand class? I’m trying to debug an instruction selection issue I think. It’s hard to find documentation on what the MO properties mean. Thanks, Carl

Hi Sergei, our use of target flags will be on immediate register operands if I am not mistaken (and if not we can always encode it as such)? I guess you are refering to the hexagon backend needing to distinguish between instances of an instruction that uses a constant value that can fit into the 4 byte of the instruction and one that encodes the immediate in an extra instruction slot (what we

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

I am observing poor instruction scheduling in my out-of-tree target. The problem is an over-constrained scheduling DAG. In particular, the DAG includes spurious output dependencies on physical, non-register-allocatable registers. MISched already includes code to avoid this problem. However that code relies on information clobbered by the earlier pass LiveVariables. I wonder whether this is a

Hi Sergei, It seems to me that you can represent the semantics of a conditional instruction by adding a use of the conditionally defined register to the instruction. The value of the output register of an instruction is either the value of the instruction if it was conditionally executed or the value of the output register before the instruction. The Bundle would be: BUNDLE %PC<imp-def>,

Hi, I have a problem regarding sub-register definitions and LiveIntervals on our target. When a subregister is defined, other parts of the register are always left untouched - they are neither read or def:ed. It however seems that Codegen treats subregister definitions as somehow clobbering the whole register. The SSA-code looks like this after isel: (Reg0 and Reg1 are 16bit registers. Reg2,

I've recently sync'd to a newer version of LLVM(Apple branch 2326 from Apple branch 2323.8) that changed the interface to addCommonCodeGenPasses which caused the default implementation to be executed instead of my overriding implementation. This default implementation has DeadMachineInstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything