similar to: [LLVMdev] LiveInterval Questions

On Thursday 17 January 2008 13:03, Evan Cheng wrote: > > So why does the live range extend throughout the entire basic block? > > > > %reg1055 doesn't appear anywhere else in the program so it shouldn't > > be > > live-in to the block. > > It could be a bug. Can you get me a test case? I'll see if I can whittle it down. It's a pretty huge

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>

Andy, Jacob, I have ported Hexagon MI scheduler 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*

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

LiveInterval.cpp. // that v is live at i'. In this implementation intervals can have holes, // i.e. an interval might look like [1,20), [50,65), [1000,1001). Each // individual range is represented as an instance of LiveRange, and the whole // interval is represented as an instance of LiveInterval. What cause these holes? -- Tzu-Chien Chiu - XGI Technology, Inc. URL:

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>

Hrm, I see a bug here. Let's say the liverange in question is [13,20) and the interval it's being merged to is something like this: [1, 4), [10, 15) IP = std::upper_bound(IP, end(), Start); if (IP != begin() && IP[-1].end > Start) { if (IP->valno != LHSValNo) { ReplacedValNos.push_back(IP->valno); IP->valno = LHSValNo; //

On Wednesday 30 January 2008 15:06, Evan Cheng wrote: > Hrm, I see a bug here. Let's say the liverange in question is [13,20) > and the interval it's being merged to is something like this: [1, 4), > [10, 15) > > IP = std::upper_bound(IP, end(), Start); > if (IP != begin() && IP[-1].end > Start) { > if (IP->valno != LHSValNo) { >

I just ran into a problem here. I'm in SimpleRegisterCoalescing at the point where EXTRACT_SUBREG coalescing updates live ranges of aliased registers (around line 473 of SimpleRegisterCoalescing.cpp). There's a call to MergeValueInAsValue at line 50. MergeValueInAsValue has this code: void LiveInterval::MergeValueInAsValue(const LiveInterval &RHS,

Andy, I've described that issue (see below) when you were out of town... I think I am getting more context on it. Please take a look... So, in short, when the new MI scheduler performs move of an instruction, it does something like this: // Move the instruction to its new location in the instruction stream. MachineInstr *MI = SU->getInstr(); if (IsTopNode) {

AFAIK std::upper_bound() would not return end(), right? Evan On Jan 29, 2008, at 3:08 PM, David Greene wrote: > I just ran into a problem here. I'm in SimpleRegisterCoalescing at > the point > where EXTRACT_SUBREG coalescing updates live ranges of aliased > registers (around line 473 of SimpleRegisterCoalescing.cpp). > > There's a call to MergeValueInAsValue at line

On Jan 30, 2008, at 1:21 PM, David Greene wrote: > On Wednesday 30 January 2008 15:06, Evan Cheng wrote: >> Hrm, I see a bug here. Let's say the liverange in question is [13,20) >> and the interval it's being merged to is something like this: [1, 4), >> [10, 15) >> >> IP = std::upper_bound(IP, end(), Start); >> if (IP != begin() &&

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'

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:

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

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

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,

On Mar 8, 2011, at 1:07 AM, Olaf Krzikalla wrote: > 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 >

On Wednesday 30 January 2008 02:02, Evan Cheng wrote: > AFAIK std::upper_bound() would not return end(), right? Yes, it can return end(). In fact that's exactly what I'm seeing. std::upper_bound is just binary search and returns where the element should be inserted to retain ordering. So for example, if my iterator range is over: 1 2 3 4 5 and I call std::upper_bound(begin(),

Thanks Matthias I can also use the method intervalIsInOneMBB() from LiveIntervals class to relate a LiveInterval to a MachineBasicBlock, right? Em 04/09/2015 2:26 PM, "Matthias Braun" <mbraun at apple.com> escreveu: > There is no direct support for this, but you can use > LiveIntervalAnalysis::getMBBStartIndex()/getMBBEndIndex()/getMBBFromIndex() > to relate the