similar to: [LLVMdev] Comparison mismatch causes assert using VStudio STL

Thanks. One question though. Should getMBBFromIndex() assert if given an index out of the range or simply returns a NULL pointer? I would think the later makes it a bit more friendly. Evan On Feb 8, 2008, at 8:59 AM, Roman Levenstein wrote: > Hi Evan, > > Here is a patch for the LiveIntervalAnalysis that we discussed. > > --- Evan Cheng <evan.cheng at apple.com>

Hi Evan, --- Evan Cheng <evan.cheng at apple.com> wrote: > Thanks. One question though. Should getMBBFromIndex() assert if given > an index out of the range or simply returns a NULL pointer? I would > think the later makes it a bit more friendly. Yes. It would be more friendly, probably. I can submit such a patch, if you think it suits better. On the other hand I want to

Hi Evan, Here is a patch for the LiveIntervalAnalysis that we discussed. --- Evan Cheng <evan.cheng at apple.com> schrieb: > > 1) What is the easiest way to understand which MBB a given > instruction index belongs to? All the required information is > available in the > > MBB2IdxMap of the LiveIntervalAnalysis class. Would it be useful > to add a small function

On Feb 10, 2008, at 11:44 PM, Roman Levenstein wrote: > Hi Evan, > > --- Evan Cheng <evan.cheng at apple.com> wrote: > >> Thanks. One question though. Should getMBBFromIndex() assert if given >> an index out of the range or simply returns a NULL pointer? I would >> think the later makes it a bit more friendly. > > Yes. It would be more friendly, probably.

Hello llvm dev peeps I would like to use an LLVMBuilder pointer as a base pointer to reference either an LLVMBuilder or an LLVMFoldingBuilder. As the methods in the Folding builder have the same names as the base class, I thought about submitting a patch whereby the base class methods would become virtual. However, the base class methods return specific types while the Folding builder, for

Hi I'm seeing something probably related to this. I'm getting an assert from the lower_bound in LiveIntervals::findLiveinMBBs (from a checking std:: VS2005 implementation). Idx2MBBMap has two elements in it, both of which have a .first of 0. (I believe because of an empty MBB in the function below, so StartIndex doesn't advance). scott On Wed, Apr 16, 2008 at 2:52 AM, Roman

Hi, > Another option that was discussed in #llvm is to nuke LLVMBuilder and > rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, I'd > argue for a flag in the Builder that could retain the old non-folding > functionality for debugging purposes. this plan sounds good to me. However it's not clear to me how useful a debug flag would really be. Ciao, Duncan.

Can you file a bug so I don't forget? I'm a little occupied right now. But I'll take care of this soon. Evan On Apr 16, 2008, at 10:52 AM, Scott Graham wrote: > Hi > > I'm seeing something probably related to this. I'm getting an assert > from the lower_bound in LiveIntervals::findLiveinMBBs (from a checking > std:: VS2005 implementation). Idx2MBBMap has two

On Apr 2, 2008, at 9:54 AM, Dominic Hamon wrote: > Hello llvm dev peeps > > I would like to use an LLVMBuilder pointer as a base pointer to > reference either an LLVMBuilder or an LLVMFoldingBuilder. As the > methods > in the Folding builder have the same names as the base class, I > thought > about submitting a patch whereby the base class methods would become >

Duncan Sands wrote: >> Another option that was discussed in #llvm is to nuke LLVMBuilder and >> rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, I'd >> argue for a flag in the Builder that could retain the old non-folding >> functionality for debugging purposes. >> > > this plan sounds good to me. However it's not clear to me how

Dominic Hamon wrote: > Duncan Sands wrote: >>> Another option that was discussed in #llvm is to nuke LLVMBuilder >>> and rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, >>> I'd argue for a flag in the Builder that could retain the old >>> non-folding functionality for debugging purposes. >>> >> >> this plan

Devang Patel wrote: > On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > >> I got the current version of LLVM via svn yesterday and modified my >> code to >> use the LLVMFoldingBuilder. Very nice! >> >> My question is this: I noticed that the folding builder doesn't fold >> some >> operations, e.g. casts. Is there some reason why? If

On Thu, 31 May 2007, Chuck Rose III wrote: > Our project is cross platform and on Windows we use VStudio 2005. > VStudio presents a couple of issues related around it's STL > implementation and also it's non-respect for the no-return semantic of > abort(). Ok. We want the source to be portable, so it's goodness to get these fixes into the main tree. > I've fixed

Hola LLVMers, Our project is cross platform and on Windows we use VStudio 2005. VStudio presents a couple of issues related around it's STL implementation and also it's non-respect for the no-return semantic of abort(). I've fixed it locally, but I'd like to send a patch so I don't have to do this every time I update from the source repository. So.... if I'm

Here are the two problem areas: RegisterInfoEmitter.cpp // Emit the subregister + index mapping function based on the information // calculated above. OS << "unsigned " << ClassName << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" << " switch (RegNo) {\n" << " default: abort(); break;\n"; ...

Hi, I've been writing an Elsa to LLVM interface. It has been going very well, I think both sets of software are very nice. At this point I've been able to compile and run a small program (sieve.c). I've also compiled a pretty complete version of printf(). (It seemed like a good choice because it touches many data types, varargs, etc.) I've had to make quite a few changes to Elsa

On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > I got the current version of LLVM via svn yesterday and modified my > code to > use the LLVMFoldingBuilder. Very nice! > > My question is this: I noticed that the folding builder doesn't fold > some > operations, e.g. casts. Is there some reason why? If I implemented > some of > these unhandled cases

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

Hi, In the LiveIntervalAnalysis::runOnMachineFunction, there is a code to compute the MBB2IdxMap, by remembering for each MBB its start and end instruction numbers: unsigned MIIndex = 0; for (MachineFunction::iterator MBB = mf_->begin(), E = mf_->end(); MBB != E; ++MBB) { unsigned StartIdx = MIIndex; for (MachineBasicBlock::iterator I = MBB->begin(), E =