similar to: IsDead, IsKill

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

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

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

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, 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

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

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

Hi all, I am attempting to implement the "reaching definitions" data-flow algorithm on (X86) MachineBasicBlocks for an analysis pass. To do this, I need to compute gen/kill sets for machine basic blocks. To start with, I am only considering the general-purpose registers, RAX-R15 and their sub-registers. Thus, I need to examine each MachineInstr to determine which register(s) it

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 Quentin and llvm-dev, I've got a regalloc-related question that you might have an opinion or answer about. In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: BUNDLE %vreg39<imp-def,dead> *

Forgive me if these questions are naive or if I'm misunderstanding something. I'm certainly very interested in seeing the MachineCopyPropagation patch finally land and stick. 1. Wouldn't function live-ins and reserved registers have started life as physical registers already? For example, wouldn't a live-in be a copy from a physical register to a virtual one allowing the flag to

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,

Just want to emphasize that on x86-64 and using Valgrind: LLVM compiled with LLVM gets 360 unexpected test fails LLVM compiled with GCC gets 22 unexpected test fails Of course I don't know how many of these are caused by this bitfield speculation issue. John On 11/21/2016 10:48 PM, regehr via llvm-dev wrote: > Alright, here's what seems to be happening... > > The testcase

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 > >

I spent some time digging into a Valgrind report of uninitialized values in LLVM r287520 built using itself. (One of quite a few such reports that comes up during a "make check".) I could use another set of eyes on the issue if someone has time. This command gives me an error: valgrind -q ./bin/llc < /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon

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, >> >> >>

Hello llvmers: I'm study Fast register allocation in codegen. I get confused with isKill flag in MachineOperand. I thin "isKill" flag the last Use Reference. But, Fast Register doesn't require LiveVariable Analysis which will mark isKill Flag for global virtual Register. So during Fast RegisterAllocation, Faster Register Allocation procedure can't determine

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

I don't understand the following code snippet in LiveIntervalAnalysis.cpp. Why changing the type of the opreand from a virtual register to a machine register? The register number (reg) is still a virtual register index (>1024). bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) { // perform a final pass over the instructions and compute spill // weights, coalesce