[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