similar to: [LLVMdev] Possible LiveIntervals bug

Roman Levenstein wrote: > Hi again, > > Now, after I fixed the graph coloring regalloc bug that was triggered > by the ARM target, I continue testing and found another bug, this time > on the XCore target. First I thought that it is again specific to my > register allocator, but it seems to be trigerred also by LLVM's > linearscan register allocator. > > I don't

After playing with the vorbis code for a while and doing tons of hacks and analysis on it, I've found it to perform very poorly with impulse signals. The MDCT seems to cause lots of spreading, and it seems to result in much worse impulse performance then mp3. What is the current plan on handling this? Will a smart quantizer be able to avoid it? I've been looking at various ways of

On Jan 13, 2009, at 11:20 AM, Richard Osborne <richard at xmos.com> wrote: > Roman Levenstein wrote: >> Hi again, >> >> Now, after I fixed the graph coloring regalloc bug that was triggered >> by the ARM target, I continue testing and found another bug, this >> time >> on the XCore target. First I thought that it is again specific to my >>

The build is failing with; LiveIntervalAnalysis.cpp:218: error: floating constant exceeds range of 'double' LiveIntervalAnalysis.cpp:253: error: floating constant exceeds range of 'double' LiveIntervalAnalysis.cpp:328: error: floating constant exceeds range of 'double' LiveIntervalAnalysis.cpp:1350: error: floating constant exceeds range of 'double' If I

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

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT)

Thanks for the updates! Minor comments: + if (!Accuracy) + // If it's not a floating point number then it must be 'fast'. + return HUGE_VALF; Can we add an assert instead of a comment? It's just as documenting and will catch any goofs. + // If it's not a floating point number then it must be 'fast'. + return !isa<ConstantFP>(MD->getOperand(0));

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

Hi again, Now, after I fixed the graph coloring regalloc bug that was triggered by the ARM target, I continue testing and found another bug, this time on the XCore target. First I thought that it is again specific to my register allocator, but it seems to be trigerred also by LLVM's linearscan register allocator. I don't know if the XCore target is stable enough in LLVM, or may be I

Evan Cheng wrote: > On Jan 13, 2009, at 11:20 AM, Richard Osborne <richard at xmos.com> wrote: > > >> Roman Levenstein wrote: >> >>> Hi again, >>> >>> Now, after I fixed the graph coloring regalloc bug that was triggered >>> by the ARM target, I continue testing and found another bug, this >>> time >>> on

On May 27, 2008, at 5:36 PM, David Greene wrote: > I've been playing around with spillers and found that the > SimpleSpiller fails > badly on a particular code. > > The problem arises because SimpleSpiller does the test > VRM.isAssignedReg(virtReg) which is implemented as: > > 00183 bool isAssignedReg(unsigned virtReg) const { > 00184 if

Hi, Any ideas why HUGE_VALF is not accepted as a float constant on Mac OS X 10.4.11 (Intel)? ./llvm/include/llvm/CodeGen/LiveInterval.h:569: error: floating constant exceeds range of 'float' ./llvm/include/llvm/CodeGen/LiveInterval.h:574: error: floating constant exceeds range of 'float' llvm/lib/CodeGen/CalcSpillWeights.cpp:111: error: floating constant exceeds range of

Hi Chandler, > Minor comments: > + if (!Accuracy) > + // If it's not a floating point number then it must be 'fast'. > + return HUGE_VALF; > > Can we add an assert instead of a comment? It's just as documenting and will > catch any goofs. Done. > > + // If it's not a floating point number then it must be 'fast'. > + return

Here's a revised patch, plus patches showing how fpmath metadata could be turned on in clang and dragonegg (it seemed safest for the moment to condition on -ffast-math rather than on one of the flags implied by -ffast-math). Major changes: - The FPMathOperator class can no longer be used to change math settings, only to read them. Currently it can be queried for accuracy info. I split the

Ok, this is a rather complicated e-mail. Please ask questions if you don't understand something. I've come across an interesting problem. I'm merging our graph coloring allocator with the code from trunk as of late last week. I have a code where a LiveInterval is spilled and some uses can be rematerialized. %reg1235 is spilled and at least one use is rematted. The remat def

The attached patch is a first attempt at representing "-ffast-math" at the IR level, in fact on individual floating point instructions (fadd, fsub etc). It is done using metadata. We already have a "fpmath" metadata type which can be used to signal that reduced precision is OK for a floating point operation, eg %z = fmul float %x, %y, !fpmath !0 ... !0 = metadata

On Wed, 7 Sep 2005, Tzu-Chien Chiu wrote: > I don't understand the following code snippet in LiveIntervalAnalysis.cpp. > > Why changing the type of the opreand from a virtual register to a > machine register? The register number (reg) is still a virtual > register index (>1024). This code isn't actually replacing the virtual register with a physreg. As you noticed, it

On Wed, 2005-09-07 at 18:24 +0800, Tzu-Chien Chiu wrote: > I though LiveVariables may be invalidated by LiveIntervals, but it's > declared not: > > void LiveIntervals::getAnalysisUsage(AnalysisUsage &AU) const > { > AU.addPreserved<LiveVariables>(); > AU.addRequired<LiveVariables>(); > ... > > LiveInterval may coalesce virtual registers and

On Wed, 2005-09-07 at 15:09 +0800, Tzu-Chien Chiu wrote: > I don't understand the following code snippet in LiveIntervalAnalysis.cpp. > > Why changing the type of the opreand from a virtual register to a > machine register? The register number (reg) is still a virtual > register index (>1024). > > > bool LiveIntervals::runOnMachineFunction(MachineFunction &fn)

On 08/09/05, Chris Lattner <sabre at nondot.org> wrote: > This code isn't actually replacing the virtual register with a physreg. Then why changing its optype? It makes the assertion fails: MachineOperand& MO = inst.getOperand(n); if (MRegisterInfo::isVirtualRegister(MO.getReg())) { assert(MachineOperand::MO_VirtualRegister == MO.getType()); ... } Is that alright? Some