[llvm-commits] [llvm] r61558 - in /llvm/trunk: include/llvm/Assembly/ lib/AsmParser/ lib/VMCore/ test/Assembler/ test/Feature/ test/Integer/ test/Linker/ test/Transforms/GlobalOpt/ test/Verifier/ tools/bugpoint/ tools/llvm-as/

[Bill Wendling]

On Jan 2, 2009, at 3:19 PM, Bill Wendling wrote:

> On Jan 1, 2009, at 11:01 PM, Chris Lattner wrote:
>> Author: lattner
>> Date: Fri Jan  2 01:01:27 2009
>> New Revision: 61558
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=61558&view=rev
>> Log:
>> Reimplement the old and horrible bison parser for .ll files with a  
>> nice
>> and clean recursive descent parser.
>>
>> This change has a couple of ramifications:
>> 1. The parser code is about 400 lines shorter (in what we maintain,  
>> not
>>  including what is autogenerated).
>> 2. The code should be significantly faster than the old code  
>> because we
>>  don't have to work around bison's poor handling of datatypes with
>>  ctors/dtors.  This also makes the code much more resistant to memory
>>  leaks.
>> 3. We now get caret diagnostics from the .ll parser, woo.
>> 4. The actual diagnostics emited from the parser are completely  
>> different
>>  so a bunch of testcases had to be updated.
>> 5. I now disallow "%ty = type opaque %ty = type i32".  There was no  
>> good
>>  reason to support this, it was just an accident of the old
>>  implementation.  I have no reason to think that anyone is actually  
>> using
>>  this.
>> 6. The syntax for sticking a global variable has changed to make it
>>  unambiguous.  I don't think anyone is depending on this since only  
>> clang
>>  supports this and it is not solid yet, so I'm not worried about  
>> anything
>>  breaking.
>> 7. This gets rid of the last use of bison, and along with it  
>> the .cvs files.
>>  I'll prune this from the makefiles as a subsequent commit.
>>
>> There are a few minor cleanups that can be done after this commit  
>> (suggestions
>> welcome!) but this passes dejagnu testing and is ready for its time  
>> in the
>> limelight.
>>
> Hi Chris,
>
> I'm getting another strange error when LLVM self-hosts:
>
> /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/ 
> llvmgcc42~dst/Developer/usr/bin/llvm-g++-4.2 -I/Volumes/Sandbox/ 
> Buildbot/llvm/full-llvm/build/llvm.sh.build/include -I/Volumes/ 
> Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/tools/opt -I/ 
> Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I/ 
> Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/tools/opt - 
> D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS  
> -O3 -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno- 
> long-long -Wunused -Wno-unused-parameter -fstrict-aliasing -Wstrict- 
> aliasing -O3 -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/ 
> llvm.sh.build/Release/bin/opt /Volumes/Sandbox/Buildbot/llvm/full- 
> llvm/build/llvm.sh.build/tools/opt/Release/AnalysisWrappers.o / 
> Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/tools/ 
> opt/Release/GraphPrinters.o /Volumes/Sandbox/Buildbot/llvm/full-llvm/ 
> build/llvm.sh.build/tools/opt/Release/PrintSCC.o /Volumes/Sandbox/ 
> Buildbot/llvm/full-llvm/build/llvm.sh.build/tools/opt/Release/opt.o   
> -L/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/ 
> Release/lib -lLLVMipo -lLLVMInstrumentation -lLLVMScalarOpts - 
> lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget - 
> lLLVMBitWriter -lLLVMBitReader -lLLVMCore -lLLVMSupport -lLLVMSystem  
> -lpthread -lm
> Undefined symbols:
>  "llvm::PATypeHolder::get() const", referenced from:
>      llvm::ELFWriter::EmitGlobal(llvm::GlobalVariable*)    in  
> libLLVMCodeGen.a(ELFWriter.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/ 
> llvm.sh.build/Release/bin/llc] Error 1
> make[1]: *** [llc/.makeall] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
>
> It's probably some weird Makefile issue that's not resolved. This  
> check in is my best guess as to what's causing it. Here's the full  
> log file:
>
> 	http://bwendling.apple.com:8020/builders/full-llvm-OSX/builds/380/steps/shell/logs/stdio
>
> Do you have an idea of what's happening?
>
Some more information: When GCC builds LLVM first, there are many  
definitions of llvm::PATypeHolder::get() hanging around:

$ nm -Am *.a | c++filt | grep PATypeHolder::get
libLLVMAnalysis.a:AliasAnalysis.o: 000021d0 (__TEXT,__textcoal_nt)  
weak external llvm::PATypeHolder::get() const
...
libLLVMCodeGen.a:ELFWriter.o:          (undefined [lazy bound])  
external llvm::PATypeHolder::get() const
...

But when LLVM compiles itself, there are no definitions of  
llvm::PATypeHolder::get():

$ nm -Am *.a | c++filt | grep PATypeHolder::get
libLLVMCodeGen.a:ELFWriter.o:          (undefined) external  
llvm::PATypeHolder::get() const

llvm::PATypeHolder::get() is defined like so in Type.h:

inline Type* PATypeHolder::get() const {
   const Type *NewTy = Ty->getForwardedType();
   if (!NewTy) return const_cast<Type*>(Ty);
   return *const_cast<PATypeHolder*>(this) = NewTy;
}

Could it be something with the inliner going awry? Before the changes  
in the parser, we got this:

$ nm -Am *.a | c++filt | grep PATypeHolder::get
libLLVMAsmParser.a:llvmAsmParser.o: 0001b1a0 (__TEXT,__textcoal_nt)  
weak external llvm::PATypeHolder::get() const
libLLVMCodeGen.a:ELFWriter.o:          (undefined) external  
llvm::PATypeHolder::get() const

So the libLLVMAsmParser.a supplied the missing symbol -- probably  
wrongly.

Thoughts? :-)

-bw