search for: liveranges

...> > If so, then isn't LiveInterval::Ranges and LiveInterval::VNInfoList > > redundant? > > What's in VNInfoList that's not in the valno member of the Ranges > > elements, > > and vice-versa? > > I am not sure if I understand your question. Multiple liveranges can > be of the same val#. Each VNInfo contains definition (if not > containing a phi merge, etc.), copy register, and kills that are not > in the liverange data structure. LiveInterval has these members: typedef SmallVector<LiveRange,4> Ranges; typedef SmallVector<VNInf...

...ing, right? Correct. > > > If so, then isn't LiveInterval::Ranges and LiveInterval::VNInfoList > redundant? > What's in VNInfoList that's not in the valno member of the Ranges > elements, > and vice-versa? I am not sure if I understand your question. Multiple liveranges can be of the same val#. Each VNInfo contains definition (if not containing a phi merge, etc.), copy register, and kills that are not in the liverange data structure. Evan > > > -Dave > ______________________________________________...

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

I'm not sure what causes this. Everything builds fine in Release mode but when I try to do a Debug build I get an error in Transforms (which causes all dependant projects to fail as well). I'm not exactly sure what causes the error, I'll try to investigate tomorrow (unless someone can figure out what it is by then). Below is the output from VS: ------ Build started: Project:

It compiles successfully with VC++ 7.1. You are apparently using VC++ 8.0, otherwise known as the Whidbey beta. The cause is no doubt due to bugs in Whidbey and this isn't the first one encountered. I'm sorry, but I cannot support beta Microsoft products (if only because I refuse to have them anywhere near my computer). All I can suggest is that you do a 'clean solution'

Hi, I am having a bit of a time trying to figure out the scheme behind the slotindexing / liverange design. There seems to be several indexes mapped to the same instruction. Why is this? I take it, that it will always be true that for a LiveRange includes instructions with slotindexes [i:j), based on calls to SlotIndexes::getInstructionIndex(MI) ? However, LiveRange.valno->def, gives an

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

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

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

Currently it will always spill / restore the whole vreg but only spilling the parts that are actually live would be a nice addition in the future. Looking at r192119': if "mtlo" writes to $LO and sets $HI to an unpredictable value, then it should just have an additional (dead) def operand for $hi, shouldn't it? Greetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira

Hi @llvm, building a debug version under MSVC 9 leads to a compiler error due to a mix of different types in a call to upper_bound. I have attached a hot-fix but I'm rather unsure if it should be applied as it is, since IMHO the reason is a MSVC library bug ("IMHO", because I don't know the requirements imposed to the predicate by the standard). Best regards Olaf Krzikalla

...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* llvm::LiveInterval::addRangeFrom(llvm::LiveRange, llvm::LiveRange*): Assertion `B->end <= Start && "Cannot overlap two LiveRanges with differing ValID's" " (did you def the same reg twice in a MachineInstr?)"' failed. has this following call stack: #3 in llvm::LiveInterval::addRangeFrom (this=0x46e99a0, LR=..., From=0x46ee4b0) at lib/CodeGen/LiveInterval.cpp:266 #4 in llvm::LiveInterval::addRange (t...

What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the other half would work. For example, this is an illegal sequence of instructions,

..., which would take a single value argument, representing a use of that value. The intrinsic would be lowered to a new invariant TargetOpcode (e.g. FAKE_USE), which serves the same purpose at the MI level. Code emission would simply ignore the new opcode. Frontends could use the intrinsic to extend liveranges of variables as desired. As a first use case, clang would accept a new option (e.g. -fkeep-this-ptr) which would cause a fake use of 'this' to be inserted at the end of a function, making it available for inspection throughout the entire function body. One important note is that since such...

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the

...mail.com>wrote: > On Sun, Aug 8, 2010 at 8:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> > wrote: > > > > On Aug 7, 2010, at 7:05 PM, Steven Noonan wrote: > >> I've been doing work on memory reduction in Unladen Swallow, and > >> during testing, LiveRanges seemed to be consuming one of the largest > >> chunks of memory. > > > > That's interesting. How did you measure this? I'd love to see your data. > > > > Note that the LiveRange struct is allocated by a plain std::vector, and > your patch doesn't chan...

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

On Aug 7, 2010, at 7:05 PM, Steven Noonan wrote: > I've been doing work on memory reduction in Unladen Swallow, and > during testing, LiveRanges seemed to be consuming one of the largest > chunks of memory. That's interesting. How did you measure this? I'd love to see your data. Note that the LiveRange struct is allocated by a plain std::vector, and your patch doesn't change that. I assume you are talking about the VNInfo s...

Say I want to find all LLVM Value*-es that a live on exit from a basic block. What's the best way? - The 'LiveRange', 'LiveVariables' and 'LiveIntervals' classes seem to be tied to register allocation. - The ./lib/Target/SparcV9/LiveVar/FunctionLiveVarInfo.h file seem to provide what I need, but it's no a public header. - Volodya

On Sun, Aug 8, 2010 at 8:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 7, 2010, at 7:05 PM, Steven Noonan wrote: >> I've been doing work on memory reduction in Unladen Swallow, and >> during testing, LiveRanges seemed to be consuming one of the largest >> chunks of memory. > > That's interesting. How did you measure this? I'd love to see your data. > > Note that the LiveRange struct is allocated by a plain std::vector, and your patch doesn't change that. I assume you are talk...