search for: liverange

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

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&g...

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 %r...

...or(s), 0 warning(s) ------ Build started: Project: CodeGen, Configuration: Debug Win32 ------ Compiling... LiveInterval.cpp c:\Program Files\Microsoft Visual Studio 8\VC\include\xutility(196) : error C2678: binary '<' : no operator found which takes a left-hand operand of type 'llvm::LiveRange' (or there is no acceptable conversion) c:\Program Files\Microsoft Visual Studio 8\VC\include\algorithm(1449) : see reference to function template instantiation 'bool std::_Debug_lt<_Ty,llvm::LiveRange>(_Ty1,_Ty2,const char *)' being compiled with [...

...------ Build started: Project: CodeGen, Configuration: Debug Win32 ------ >Compiling... >LiveInterval.cpp >c:\Program Files\Microsoft Visual Studio 8\VC\include\xutility(196) : >error C2678: binary '<' : no operator found which takes a left-hand >operand of type 'llvm::LiveRange' (or there is no acceptable >conversion) > c:\Program Files\Microsoft Visual Studio >8\VC\include\algorithm(1449) : see reference to function template >instantiation 'bool >std::_Debug_lt<_Ty,llvm::LiveRange>(_Ty1,_Ty2,const char *)' being >compiled >...

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

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 liverange by [MBB0->MBB1->MBB2]. I will find R4 first is killed, then is used. It can not unlogisch. Attually R4 just is <Used>. It will cause my optimization pass crash(Actually, I ingore Li...

...following code: 16B %vreg0:ssub_0<def,read-undef> = ... 32B %vreg0:ssub_1<def> = ... 48B = %vreg0 64B = %vreg0:ssub_0 80B %vreg0 = ... 96B = %vreg0:ssub_1 will be represented as the following live range(s): Common LiveRange: [16r,32r)[32r,64r),[80r,96r) SubRange with Mask 0x0004 (=ssub_0): [16r,64r)[80r,80d) SubRange with Mask 0x0008 (=ssub_1): [32r,48r)[80r,96r) Patches/Changes: * Moves live range management code in the LiveInterval class to a new class LiveRange, move the previous LiveRange class (which wa...

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 thing. > R4 is marked <kill> at MBB0. If I scan R4's liverange by [MBB0->MBB1->MBB2]. I will find R4 first is killed, then is used. It can not un...

.... > 32B %vreg0:ssub_1<def> = ... > 48B = %vreg0 > 64B = %vreg0:ssub_0 > 80B %vreg0 = ... > 96B = %vreg0:ssub_1 > > will be represented as the following live range(s): > > Common LiveRange: [16r,32r)[32r,64r),[80r,96r) > SubRange with Mask 0x0004 (=ssub_0): [16r,64r)[80r,80d) > SubRange with Mask 0x0008 (=ssub_1): [32r,48r)[80r,96r) > > Patches/Changes: > * Moves live range management code in the LiveInterval class to a new > class LiveRang...

...e by the standard). Best regards Olaf Krzikalla Index: lib/CodeGen/LiveInterval.cpp =================================================================== --- lib/CodeGen/LiveInterval.cpp (revision 127221) +++ lib/CodeGen/LiveInterval.cpp (working copy) @@ -39,6 +39,9 @@ bool operator()(const LiveRange &A, SlotIndex B) const { return A.end < B; } + bool operator()(const LiveRange &A, const LiveRange &B) const { + return A.end < B.end; + } }; }

...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* 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 i...

...t; 32B %vreg0:ssub_1<def> = ... >> 48B = %vreg0 >> 64B = %vreg0:ssub_0 >> 80B %vreg0 = ... >> 96B = %vreg0:ssub_1 >> >> will be represented as the following live range(s): >> >> Common LiveRange: [16r,32r)[32r,64r),[80r,96r) >> SubRange with Mask 0x0004 (=ssub_0): [16r,64r)[80r,80d) >> SubRange with Mask 0x0008 (=ssub_1): [32r,48r)[80r,96r) >> >> Patches/Changes: >> * Moves live range management code in the LiveInterval class to a new >> class Live...

Hello! At Sony we've seen some serious customer interest in having the 'this' pointer visible throughout an entire function during debugging. However, optimizations may eliminate it after its last use, so we've been looking for a way to artificially extend its liverange to the end of the function. So far, the most compelling way we can think of, and one we have used successfully in the past in at least one other compiler, is to create a 'fake use' of the 'this' pointer at the end of the function, compelling the rest of the compiler to not optimize...

...32B %vreg0:ssub_1<def> = ... >> 48B = %vreg0 >> 64B = %vreg0:ssub_0 >> 80B %vreg0 = ... >> 96B = %vreg0:ssub_1 >> >> will be represented as the following live range(s): >> >> Common LiveRange: [16r,32r)[32r,64r),[80r,96r) >> SubRange with Mask 0x0004 (=ssub_0): [16r,64r)[80r,80d) >> SubRange with Mask 0x0008 (=ssub_1): [32r,48r)[80r,96r) >> >> Patches/Changes: >> * Moves live range management code in the LiveInterval class to a new >> class Liv...

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

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

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