[LLVMbugs] [Bug 4738] Invalid strcmp optimization involving weak GV initializers

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Tue Aug 18 17:23:24 PDT 2009


http://llvm.org/bugs/show_bug.cgi?id=4738


Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gohman at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Dan Gohman <gohman at apple.com>  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.



More information about the llvm-bugs mailing list