similar to: [LLVMdev] MSVC compiling issue

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 >

Hi @llvm, Am 08.03.2011 20:14, schrieb Jakob Stoklund Olesen: > Is that extra method getting called? What happens if you stick assert(0) in there? That won't work either (that is, the assert fires). In debug mode the MSVC lib tries to test the ordering of the sequence. And it uses the yielded predicate for this (which in this particular case is a very bad idea). > I hoped the

On Mar 9, 2011, at 2:32 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote: > Hi @llvm, > > Am 08.03.2011 20:14, schrieb Jakob Stoklund Olesen: >> Is that extra method getting called? What happens if you stick assert(0) in there? > That won't work either (that is, the assert fires). In debug mode the MSVC lib tries to test the ordering of the sequence. And it

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'

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,

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

MSVC 9 asserts that the comparision function is symmetric, because of what was unclear wording in the standard (there are posts explaining this in the boost archive for those interested). The workaround is to supply the other overload of the comparator. Sorry Jacob, didn't reply all last time. On Wed, Mar 9, 2011 at 7:20 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > On Mar

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

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

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

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*

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>

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

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

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

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

Hello, I have a minimal testcase which crashes RegisterCoalescer in my out-of-tree target. It only crashes in Debug builds of llc---not in Release builds. Also, interesting to note that the x86 backend lowers this same testcase successfully. I did a quick search of bugs.llvm.org and found no matches. This implies that the problem is in my backend and/or how my backend interacts with