search for: misoptimizations

> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, 9 Jan 2017 11:43:17 -0600 > Wei Ding via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> I want an efficient way to implement function pow in LLVM instead of >> invoking pow() math built-in. For algorithm part, I am clear for the

Happy 2011, everybody! It seems -tailcallopt prevents tailcall optimization when both caller and callee have ccc, even when it is optimized without an option -tailcallopt. Is it intended or misoptimized? In X86ISelLowering.cpp:X86TargetLowering::IsEligibleForTailCallOptimization(): if (GuaranteedTailCallOpt) { if (IsTailCallConvention(CalleeCC) && CCMatch) return true;

Chris Lattner <clattner at apple.com> writes: >> No; sext i32 undef to i64 returns an extraordinary thing. It's a >> 64-bit value where the low 32 bits are undef, and the high >> 32 bits are sign extension from whatever bit 31 happened to be. > > More precisely, the high 33 bits are known to be the same. I think that's a very risky assumption. The name

On Dec 5, 2011, at 7:44 PM, Dan Gohman wrote: > > On Dec 5, 2011, at 5:50 PM, me22 wrote: > >> On Thu, Dec 1, 2011 at 09:23, Dan Gohman <gohman at apple.com> wrote: >>> >>> int a = INT_MAX, b = 1; >>> long c = (long)(a + b); >>> >>> What is the value of c, on an LP64 target? >>> >>> If a and b are promoted to

> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/12/2017 9:33 AM, Mehdi Amini via llvm-dev wrote: >>> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Mon, 9 Jan 2017 11:43:17 -0600 >>> Wei Ding via llvm-dev <llvm-dev at

Hi, everyone, I'd like to propose adding a nofree function attribute to indicate that a function does not, directly or indirectly, call a memory-deallocation function (e.g., free, C++'s operator delete). Clang/LLVM can currently misoptimize functions that:  1. Have a reference argument.  2. Free the memory backing the object to which the reference is bound during the function's

On Dec 5, 2011, at 5:50 PM, me22 wrote: > On Thu, Dec 1, 2011 at 09:23, Dan Gohman <gohman at apple.com> wrote: >> >> int a = INT_MAX, b = 1; >> long c = (long)(a + b); >> >> What is the value of c, on an LP64 target? >> >> If a and b are promoted to 64-bit, c is 0x0000000080000000. >> >> In a world where signed add overflow

It's in debug. I'm having a look at the assembler it's producing right now and it's definitely a little odd for what should be a simple assignment in zeroSignificand. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dale Johannesen Sent: Wednesday, September 05, 2007 2:39 PM To: LLVM Developers Mailing

On Sep 5, 2007, at 2:21 PM, Chuck Rose III wrote: > Hola LLVMers, > > > > I’m getting a crash when using ConstantFP::get. > > > > I can repro it by adding one line to the Fibonacci example program: > > > > int main(int argc, char **argv) { > > int n = argc > 1 ? atol(argv[1]) : 24; > > > > // Create some module to put our function

Hola Dale, I spent some time walking through what's going on with a friend of mine from VStudio. Category is given 2 bits in the APFloat class definition. It's sign extending the enum value for the comparisons when it loads it out of the class, so the 2 becomes a -2 and the comparison fails. He sent me a piece of code which I might be able to use to force the issue. I'll update

Hola LLVMers, I'm getting a crash when using ConstantFP::get. I can repro it by adding one line to the Fibonacci example program: int main(int argc, char **argv) { int n = argc > 1 ? atol(argv[1]) : 24; // Create some module to put our function into it. Module *M = new Module("test"); // We are about to create the "fib" function: Function

On 4/3/23 15:50, Michael Milton wrote: > Okay, but I'm afraid this will only mean something to Rust users. The > reason being that we encountered this issue in extendr: a Rust > extension library for R. The specific compiler errors we encounter > happen because bindgen (the Rust code generation library) read the > changed R header files, and generated a new type definition

On 01/20/2010 05:54 PM, John Regehr wrote: > Hi folks, > > I've posted an updated code size comparison between LLVM, GCC, and > others here: > > http://embed.cs.utah.edu/embarrassing/ > > New in this version: > > - much larger collection of harvested functions: more than 360,000 > > - bug fixes and UI improvements > > - added the x86 Open64

I'm building tool-chain for processor without integer MUL. So, I've defined __mulsi3 for integer multiplication (int32). Now I've got a problem with int64 multiplication which is implemented in libgcc2.c. Segfualt due to infinite recursion in i64 soft multiplication (libgcc2, __muldi3). LLVM-GCC (for my target) misoptimizes code if -O2 is passed. It promotes i32 multiplication to

On Jan 1, 2011, at 4:20 PM, NAKAMURA Takumi wrote: > Happy 2011, everybody! > > It seems -tailcallopt prevents tailcall optimization when both caller > and callee have ccc, > even when it is optimized without an option -tailcallopt. Sorry, I don't understand your question. What do you mean by both caller and callee have ccc? Evan > Is it intended or misoptimized? >

On Tue, Dec 6, 2011 at 9:18 AM, David A. Greene <greened at obbligato.org> wrote: > Chris Lattner <clattner at apple.com> writes: > >>> No; sext i32 undef to i64 returns an extraordinary thing. It's a >>> 64-bit value where the low 32 bits are undef, and the high >>> 32 bits are sign extension from whatever bit 31 happened to be. >> >>

I just checked in an important changeset into the LLVM tree to fix a major problem with the getelementptr instruction (which can cause misoptimization in some cases, and wierd semantics in the backend). Instead of using 'uint' arguments to index into SequentialTypes (arrays and pointers) we now use 'long' arguments. In the very near future, I'll update all of the LLVM

One useful topic would be : How to use bug point to identify wrong code gen bugs. - Devang

Hi Tomas, Thanks for this explanation. As you can probably tell I'm not much of a C person, so I didn't realise this change would be invisible to C users. I suppose R's stability contract only applies to C, and therefore changes that break other languages such as Rust are out of scope. You are right that this error is confused by bindgen's inability to handle anonymous types, but

I've made quite a bit of progress getting bugpoint to work with our (non-gcc) tools. In fact I caught the alignment bug I recently posted about using it. But it's not there yet. In particular, I am seeing this scenario a lot (comments in brackets): *** Found miscompiling pass: -instcombine Emitted bitcode to 'bugpoint-passinput.bc' [ Good! This is progress! ] *** You can