search for: pr711

...led. Therefore, the register allocator loops for > ever. > > > > I would be grateful, if someone would confirm that this is a bug. > And > > of course, it would be very nice if one of the RegAlloc Gurus could > fix > > it ;) > > This is likely a bug, probably PR711. > > Unfortunately, this isn't super easy to fix, I don't have plans to do > so in the near future... OK. I looked at the PR711 at http://llvm.org/bugs/show_bug.cgi?id=711 Indeed, it sounds as the same bug. Two questions: 1) At least, it would be better if LLVM would crash on an...

...vals now due to (1), they > cannot be spilled. Therefore, the register allocator loops for ever. > > I would be grateful, if someone would confirm that this is a bug. And > of course, it would be very nice if one of the RegAlloc Gurus could fix > it ;) This is likely a bug, probably PR711. Unfortunately, this isn't super easy to fix, I don't have plans to do so in the near future... -Chris > --- Evan Cheng <evan.cheng at apple.com> wrote: >> >> On Dec 20, 2006, at 2:06 PM, Roman Levenstein wrote: >> >>>> >>>> This will p...

Hi, I was working on extending soft-float support for handling expansion of i64 and f64 into i16, i.e. on supporting the expansion of long values of illegal types into more then two parts. For that I modified SelectionDAGLowering::getValue() and several other functions. This seems to work now on my test-cases, but while testing it I ran into a different problem. I have the impression that I

On Dec 20, 2006, at 2:06 PM, Roman Levenstein wrote: >> >> This will probably require a slightly more extensive patch to >> legalizer. The current mechanism assumes either 1->1 or 1->2 >> expansion. > > Exactly. This is what I meant with "more chellenging";) It is assumed > at several places that 1->1 or 2->2 expanstions are taking place. A