similar to: [LLVMdev] InlineSpiller.cpp bug?

Hi Quentin, I have tried to find a test case for an official target, but failed. It seems to be a rare case. To do it, I added the 'else' clause in the following: ... if (VNI->def == OrigVNI->def) { DEBUG(dbgs() << "orig phi value\n"); SVI->second.DefByOrigPHI = true; SVI->second.AllDefsAreReloads = false; propagateSiblingValue(SVI); continue;

Hi Quentin, I have rerun the test case on a recent commit, so the numbers have changed. There are also now a few more basic blocks very small basic blocks in the function, and therefore there are some slight differences. I tried to go back to earlier commits, without success for some reason... This is however very similar, except that there becomes two COPYs back to sibling value after the loop.

Hi Jonas, Thanks for your patience. After spending some time looking at the additional output you gave me, I agree that your fix is the right one. I was worried that this problem may arise because we were spilling not real user, but in fact what I thought was the problem is an optimization we could do :). See my comments inlined for a few nitpicks before you commit. Thanks again, -Quentin On

Hello. Does anybody have an idea why I'm getting the error below when using llc with arguments -O1 -disable-cgp? Note that this error is not given when using llc -O0. (I'd like to mention also I'm using custom Instruction selection for BUILD_VECTOR, which gets converted in my back end's machine instrution VLOAD_D, although the custom code seems to always select

I've hit a bug in a refactored version of coalescing and I'm trying to understand what is going on. In particular, I'm curious about this line in SimpleRegisterCoalescing.cpp: 00710 LHSValsDefinedFromRHS[VNI] = RHS.getLiveRangeContaining(VNI->def-1)->valno; Why VNI->def-1? The bug I'm seeing is that RHS returns a NULL LiveRange because it doesn't contain

On Tuesday 25 September 2007 10:49, David Greene wrote: > I've hit a bug in a refactored version of coalescing and I'm trying to > understand what is going on. In particular, I'm curious about this > line in SimpleRegisterCoalescing.cpp: > > 00710 LHSValsDefinedFromRHS[VNI] = > RHS.getLiveRangeContaining(VNI->def-1)->valno; > > Why VNI->def-1?

LLVM is assuming this: struct InstrSlots { enum { LOAD = 0, USE = 1, DEF = 2, STORE = 3, NUM = 4 }; So VNI->def is always modulo 2. For coalescing, it's checking if the RHS is live at the "use" cycle. So it's checking VNI->def-1. Evan On Sep 25, 2007, at 8:55 AM, David Greene wrote: > On Tuesday

The InlineSpiller in 3.1 is quite different from the old spiller so I am trying to slog through the code and learn a bit. On a spill, the spiller calls traceSiblingValue. I gather that this is supposed to find the "original" def point of a value, checking back through copies, phis, etc. At the end we have an interval being spilled and the original def instruction of the value. For

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

On Sep 19, 2012, at 10:13 AM, dag at cray.com wrote: > The InlineSpiller in 3.1 is quite different from the old spiller so I am > trying to slog through the code and learn a bit. > > On a spill, the spiller calls traceSiblingValue. I gather that this is > supposed to find the "original" def point of a value, checking back > through copies, phis, etc. At the end we

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,

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

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

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

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>

On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote: > /// Information about how the value is assigned. > - LocInfo HTP : 7; > + LocInfo HTP : 6; > > Do you know why this change is needed? Are we running out of bits? HTP was't using all of these bits. I needed the hasCustom bit to come from somewhere unless we wanted to grow this struct, so I

Thanks. More questions :-) /// Information about how the value is assigned. - LocInfo HTP : 7; + LocInfo HTP : 6; Do you know why this change is needed? Are we running out of bits? - NeededStackSize = 4; - break; - case MVT::i64: - case MVT::f64: - if (firstGPR < 3) - NeededGPRs = 2; - else if (firstGPR == 3) { - NeededGPRs = 1; - NeededStackSize = 4; -

This time with the test cases actually attached. deep On Tue, Feb 17, 2009 at 4:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote: >> /// Information about how the value is assigned. >> - LocInfo HTP : 7; >> + LocInfo HTP : 6; >> >> Do you know why this change

Sorry I haven't gotten back to you earlier. I have been busy. I ran some MultiSource/Benchmark earlier today. Looks like there are some failures: Fhourstones-3.1, Fhourstones, McCat/08-main, MiBench/ consumer-lame, Olden/Power, Olden/voronoi, mafft/pairlocalign, and sim. Are you able to test them on your end? Evan On Feb 17, 2009, at 4:42 PM, Sandeep Patel wrote: > This time with