search for: misoptimized

> 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; return false; } I know -tailcallopt changes calling conversion of fastcc to callee-pop. ps. I am twe...

...ion. The name "undef" does not convey that at all. >> operands and opcodes. It's quite magical. > > It's actually not that magical. It's also essential that we have this > behavior, otherwise normal bitfield code has "undefined" behavior and > is misoptimized. This is why the result of "undef & 1" is known to > have high bits zero. Well sure, because we know (x & 1) has the high bits set to zero for any value of x. In the sext case, we know nothing about the high bits because we don't know what bit 32 was/is. Yes, we know...

...r bit 31 happened to be. More precisely, the high 33 bits are known to be the same. > operands and opcodes. It's quite magical. It's actually not that magical. It's also essential that we have this behavior, otherwise normal bitfield code has "undefined" behavior and is misoptimized. This is why the result of "undef & 1" is known to have high bits zero. -Chris

> 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

...ou also add a main() for each of these files, and do a very simple test that the optimized functions actually work? At least for functions that take only integers and return integers this could be automated if you compare -O0 output with the optimized outputs. The neon_helper.c testcase is clearly misoptimized by gcc-head here: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/compare_clang-head_gcc-head/compare_23BD1620_disasm.shtml Try calling it like this: int main() { printf("%d\n", helper_neon_rshl_s8(0x12345, 15)); return 0; } Prints 74496 here, and not 0 (gcc-head optimized...

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

...> > 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? > > In X86ISelLowering.cpp:X86TargetLowering::IsEligibleForTailCallOptimization(): > > if (GuaranteedTailCallOpt) { > if (IsTailCallConvention(CalleeCC) && CCMatch) > return true; > return false; > } > > I know -tailcallopt changes calling conv...

...ot; does not > convey that at all. > >>> operands and opcodes. It's quite magical. >> >> It's actually not that magical.  It's also essential that we have this >> behavior, otherwise normal bitfield code has "undefined" behavior and >> is misoptimized.  This is why the result of "undef & 1" is known to >> have high bits zero. > > Well sure, because we know (x & 1) has the high bits set to zero for any > value of x.  In the sext case, we know nothing about the high bits > because we don't know what bit 32 w...

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

...ular, 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 reproduce the problem with: opt bugpoint-passinput.bc -instcombine Checking to see if the program is misoptimized when these functions are run through the pass: main sub0_ init_ Removing function main Removing function sub0_ Removing function init_ Optimizing functions being tested: done. Checking to see if the merged program executes correctly: <llc> About to run: llc -o bugpoint-test-program.bc.l...