http://llvm.org/bugs/show_bug.cgi?id=4738
Dan Gohman <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Dan Gohman <[email protected]> 2009-08-18 19:23:24 --- (In reply to comment #2) > (In reply to comment #1) > > The bug may exist, but the testcase is wrong. Take a look at the IR: > > > > @fake_init = weak_odr constant [2 x i8] c"y\00" ; <[2 x i8]*> [#uses=2] > > > > The linkage is ODR linkage, meaning that the initializer is reliable. > > Why is llvm-gcc producing this? It does it because gcc itself is happy > > to do constant folding and other optimizations using the initial value of > > weak constants. Since constant folding occurs before IR generation, it > > seemed pointless not to allow LLVM to do further optimizations using the > > initial value. There's been some discussion about this kind of transform > > on the gcc mailing lists, and the conclusion was that it is valid. LLVM > > gives you more choice: generate weak_odr linkage if the front-end wants to > > allow this kind of thing, otherwise generate weak linkage. > > Well if this optimization is valid I'd like to at least see a warning about > it, > at least when using clang -Wall. The optimizer isn't currently well-positioned to emit warnings, but I agree that it'd be nice if there were a way to warn when an invalid assumption is encountered. > > In the LLVM context it is valid to use the initializer if the linkage is > > weak_odr, but not if it is weak. Does simplifylibcalls still do the > > transform if the linkage type of @fake_init is weak? > > > > It does a different optimization then, which still aborts: > - %2 = call i32 @strcmp(i8* getelementptr ([2 x i8]* @fake_init, i32 0, i64 > 1), i8* getelementptr ([2 x i8]* @.str, i64 0, i64 0)) nounwind readonly; > <i32> > [#uses=1] > + %strcmpload = load i8* getelementptr ([2 x i8]* @.str, i64 0, i64 0); <i8> > [#uses=1] > + %2 = zext i8 %strcmpload to i32 ; <i32> [#uses=1] > > It checks only the first byte (because it knowns the string length). This is fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/084902.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
