similar to: [LLVMdev] Build failure due to -pedantic?

Chris said something about Xcode fixing this ? It doesn't happen with the GCC 3.4.6 compiler on Linux so that's why I missed it, but I thought Chris had fixed it. Reid. On Fri, 2006-11-03 at 08:48 -0400, Jim Laskey wrote: > The build is failing with; > > LiveIntervalAnalysis.cpp:218: error: floating constant exceeds range > of 'double' >

At line 1155 of LiveIntervalAnalysis.cpp (in LiveIntervals::rewriteInstructionsForSpills), should the condition be: if (ImpUse && MI != ReMatDefMI && MI != ReMatOrigDefMI) instead of: if (ImpUse && MI != ReMatDefMI) ? After all, ReMatDefMI is a clone of the original def instruction (ReMatOrigDefMI). I'm seeing bad things happen, with intervals getting HUGE_VALF

all, this is all probably very old news and probably fixed in a later OSX, but..... on my 10.4.11 machine, math.h has (IMHO this bug) #define HUGE_VALF 1e50f this compiles when I build LLVM using "configure", but not with "cmake", probably to do with different C-standard-ness and pedantic-ness switches.... I would recommend LLVM Support not import the

Chris Lattner wrote: >I think that we should switch to C constants in this case. Can you try >#include <math.h> and use HUGE_VAL instead? > It works: [finna at coplin11 ~/test]$ cat tst.cpp #include <limits> #include <iostream> #include <math.h> int main() { std::cerr << std::numeric_limits<float>::infinity() << "\n"; std::cerr

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

On Thu, May 06, 2004 at 04:06:27PM +0200, Finn S Andersen wrote: > Chris Lattner wrote: > > >I think that we should switch to C constants in this case. Can you try > >#include <math.h> and use HUGE_VAL instead? > > > It works: > > [finna at coplin11 ~/test]$ cat tst.cpp > #include <limits> > #include <iostream> > #include

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 Wed, 5 May 2004, Finn S Andersen wrote: > Chris Lattner wrote: > > >Could you try compiling and running this program: > > > >--- > >#include <limits> > >#include <iostream> > >int main() { > > std::cerr << std::numeric_limits<float>::infinity() << "\n"; > >} > >--- > > > > > Sure

One of my pass requires LiveIntervals to build the interference graph, because LiveVariables do not provide an interface to iterate through all viritual registers. But LiveIntervalAnalysis.h is not in "include/llvm/CodeGen", so I have to either include it by: #include "../../llvm/lib/CodeGen/LiveIntervalAnalysis.h" or point my project include path to

On 8/7/06, Chris Lattner <sabre at nondot.org> wrote: > > On Sun, 6 Aug 2006, Anton Vayvod wrote: > > I'm developing a register allocator that works iteratively. It spills > some > > virtual registers on each iteration until all the rest have physical > ones > > assigned. > > Take a look at the linear scan allocator. It is also iterative: it uses >

Hello, I'm getting an assertion in register allocator, specifically in LiveIntervalAnalysis.h, method LiveIntervals::getInstructionIndex: unsigned getInstructionIndex(MachineInstr* instr) const { Mi2IndexMap::const_iterator it = mi2iMap_.find(instr); assert(it != mi2iMap_.end() && "Invalid instruction!"); return it->second; } The crash happens

Dear LLVM Community, I am one of the summer of coders working on LLVM this year. My project is to implement the ABCD algorithm for array bounds checking, and also a bitwidth analysis that maps variables to an approximation of its size in bits. To implement this, I will have to simulate a intermediate representation called SSI (Static Single Information) form on top of LLVM SSA

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*

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 =

Hello, I am a newbie to LLVM as well as compilers and I am hoping for some direction in finding an instance of where a Reaching Definition Analysis is being implemented within LLVM. I have referenced the sources files, initially hoping to find an explicit ReachingDefinitionAnalysis.cpp file ;-) but with no such luck. Other than that I have found the files SimpleRegisterCoalescing.cpp and the

On darwin x86, I'm seeing: $ make ENABLE_OPTIMIZED=1 llvm[2]: Compiling LiveIntervalAnalysis.cpp for Release build Assertion failed: (MVT::isInteger(LVT)), function MeetsMaxMemopRequirement, file /Volumes/mrs5/net/llvm/llvm/lib/CodeGen/ SelectionDAG/SelectionDAGISel.cpp, line 4230. /Volumes/mrs5/net/llvm/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1466: internal compiler error: Abort trap

On Jan 31, 2008, at 5:05 AM, Roman Levenstein wrote: > Hi, > > I'm trying to sketch an LLVM-based implementation of the Extended > Linear Scan algorithm, described in this Vivek Sarkar's paper: > http://www.cs.rice.edu/~vs3/PDF/cc2007.pdf > Sarkar reports that this version of Linear Scan produces better code > than graph-coloring regallocs and is also much faster (15x

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, I'm trying to sketch an LLVM-based implementation of the Extended Linear Scan algorithm, described in this Vivek Sarkar's paper: http://www.cs.rice.edu/~vs3/PDF/cc2007.pdf Sarkar reports that this version of Linear Scan produces better code than graph-coloring regallocs and is also much faster (15x to 68x). I already started work on the implementation of this algorithm and have a few