search for: tablegenbackend

tl;dr: is anyone opposed to making the interface to a TableGen backend be: void MyBackend(RecordKeeper &, raw_ostream & /* maybe some other args, per backend's needs */); ?? Currently, this is the "interface" for a TableGen backend: struct TableGenBackend { virtual void anchor(); virtual ~TableGenBackend() {} // run - All TableGen backends should implement the run method, which should // be the main entry point. virtual void run(raw_ostream &OS) = 0; public: // Useful helper routines... /// EmitSourceFileHeader - Output a LLVM s...

...inGW/llvm/utils/TableGen/Debug/InstrSelectorEmitter.o /C/Projects/build/MinGW/llvm/utils/TableGen/Debug/Record.o /C/Projects/build/MinGW/llvm/utils/TableGen/Debug/RegisterInfoEmitter.o /C/Projects/build/MinGW/llvm/utils/TableGen/Debug/TableGen.o /C/Projects/build/MinGW/llvm/utils/TableGen/Debug/TableGenBackend.o -lsupport -lLLVMsystem /C/Projects/build/MinGW/llvm/mklib --tag=disable-shared --tag=CXX --mode=link g++ -I/C/Projects/build/MinGW/llvm/utils/TableGen -I/C/Projects/build/MinGW/llvm/../../../src/llvm/utils/TableGen -I/C/Projects/build/MinGW/llvm/../../../src/llvm/include -I/C/Projects/build/...

>> Daniel's comments are also good. > > …success! Looks like I spoke a bit too soon. Everything works as far as the fat binaries are concerned, except that -mmacosx-version-min is set to the host’s OS version, not that of the SDK, causing errors when it tries to link against 10.6’s versions of libraries instead of 10.5’s. This patch appears to solve that; it uses the OS version

...eGen/Debug/InstrSelectorEmitter.o > /C/Projects/build/MinGW/llvm/utils/TableGen/Debug/Record.o > /C/Projects/build/MinGW/llvm/utils/TableGen/Debug/RegisterInfoEmitter.o > /C/Projects/build/MinGW/llvm/utils/TableGen/Debug/TableGen.o > /C/Projects/build/MinGW/llvm/utils/TableGen/Debug/TableGenBackend.o > -lsupport -lLLVMsystem > /C/Projects/build/MinGW/llvm/mklib --tag=disable-shared --tag=CXX > --mode=link g++ -I/C/Projects/build/MinGW/llvm/utils/TableGen > -I/C/Projects/build/MinGW/llvm/../../../src/llvm/utils/TableGen > -I/C/Projects/build/MinGW/llvm/../../../src/llvm/incl...

...Users/jyasskin/src/llvm/trunk_nolibtool/obj/utils/TableGen/Debug/TGParser.o /Users/jyasskin/src/llvm/trunk_nolibtool/obj/utils/TableGen/Debug/TGValueTypes.o /Users/jyasskin/src/llvm/trunk_nolibtool/obj/utils/TableGen/Debug/TableGen.o /Users/jyasskin/src/llvm/trunk_nolibtool/obj/utils/TableGen/Debug/TableGenBackend.o -lLLVMSupport -lLLVMSystem \ -lpthread -lm ld: unknown option: -export-dynamic collect2: ld returned 1 exit status make[2]: *** [/Users/jyasskin/src/llvm/trunk_nolibtool/obj/Debug/bin/tblgen] Error 1 make[1]: *** [TableGen/.makeall] Error 2 make: *** [all] Error 1 dhcp-172-19-103-185:~/src/ll...

For those of you who haven't noticed, I'm planning to commit a major change to the Makefile rules tomorrow evening (Tuesday) if there are no complaints about it between now and then. This needs testing on Darwin. I've heard back from Linux on many platforms and even FreeBSD, which is fantastic, but I'm told that lots of LLVMers are running Darwin and I haven't heard a peep

....modified.debug/utils/TableGen/Debug+Checks/RegisterInfoEmitter.o /tmp/ptmp/dag/build.llvm.modified.debug/utils/TableGen/Debug+Checks/SubtargetEmitter.o /tmp/ptmp/dag/build.llvm.modified.debug/utils/TableGen/Debug+Checks/TableGen.o /tmp/ptmp/dag/build.llvm.modified.debug/utils/TableGen/Debug+Checks/TableGenBackend.o -lLLVMSupport -lLLVMSystem \ -lltdl -lm -lelf /tools/llvm-tools/x86_64-unknown-linux-gnu/bin/g++ -I/tmp/ptmp/dag/build.llvm.modified.debug/utils/TableGen -I/users/dag/projects/llvm-project.modified/llvm/trunk/utils/TableGen -I/tmp/ptmp/dag/build.llvm.modified.debug/include -I/users/dag/p...

...llvm[2]: Compiling IntrinsicEmitter.cpp for Release build llvm[2]: Compiling Record.cpp for Release build llvm[2]: Compiling RegisterInfoEmitter.cpp for Release build llvm[2]: Compiling SubtargetEmitter.cpp for Release build llvm[2]: Compiling TableGen.cpp for Release build llvm[2]: Compiling TableGenBackend.cpp for Release build llvm[2]: Linking Release executable tblgen (without symbols) llvm[2]: ======= Finished Linking Release Executable tblgen (without symbols) gmake[2]: Leaving directory `/home/emil/ll/objdir-llvm/utils/TableGen' [...] --Emil

...elease build llvm[2]: Compiling RegisterInfoEmitter.cpp for Release build llvm[2]: Compiling SubtargetEmitter.cpp for Release build llvm[2]: Compiling TGLexer.cpp for Release build llvm[2]: Compiling TGParser.cpp for Release build llvm[2]: Compiling TableGen.cpp for Release build llvm[2]: Compiling TableGenBackend.cpp for Release build llvm[2]: Linking Release executable tblgen (without symbols) /usr/bin/ld: Undefined symbols: llvm::MemoryBuffer::getFileOrSTDIN(char const*, unsigned int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, long long) llvm::cl::ParseComma...

...d AFAIK the only way to really puzzle out the deep details there is to look at the source code of the TableGen backends in utils/TableGen/ and correlating that with the generated .inc files (look in your build dir) and where those .inc files are included inside lib/Target/$ARCH/; see utils/TableGen/TableGenBackends.h for an overview of what's there. There is some rough documentation about them in < http://llvm.org/docs/WritingAnLLVMBackend.html> and < http://llvm.org/docs/CodeGenerator.html>. The actual TableGen "language" is documented fairly poorly but actually has real dedicated...

On Mon, 17 Sep 2007, Emil Mikulic wrote: >> The 2.1 pre-release (version 1) is available for testing: >> http://llvm.org/prereleases/2.1/version1/ > > I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be > stale. I tried building LLVM without bison installed and got: Can you try it again without bison with these files:

...ling CodeEmitterGen.cpp > Compiling CodeGenTarget.cpp > Compiling FileLexer.cpp > Compiling FileParser.cpp > Compiling InstrInfoEmitter.cpp > Compiling InstrSelectorEmitter.cpp > Compiling Record.cpp > Compiling RegisterInfoEmitter.cpp > Compiling TableGen.cpp > Compiling TableGenBackend.cpp > Linking tblgen debug executable (without symbols) > /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function `llvm::sys::Path::is_file() const': > /usr/include/c++/3.3/bits/basic_string.h:889: undefined reference to `llvm::sys::Path::is_valid() const' > /usr/home/...

Reid, >As for Interix support in general, I'm having a hard time determining >which variant of Unix Interix implements. It seems to be partially Posix >1 and partially Posix 2 based. Do you have any further information >related to the specific standards supported by Interix? I don't want to >incorrectly categorize the Interix support. I've discussed this subject with

When I registered for dev conference, there was a field asking what I was particularly interested in learning. I didn't fill it out then , but it occurs to me now that I'd really enjoy a tutorial on how to develop a new back end. I spent some time recently reviewing existing material (documentation and code) and not making a lot of progress. Indeed, under some time pressure, I'm

Jeff/Vladimir: As with Interix, I've recently added support for FreeBSD into lib/System. Currently, the implementation of FreeBSD just uses the "generic Unix" implementation which probably should work on FreeBSD. If not, I would appreciate it if you could make patches in the FreeBSD directory. If you do, don't forget that you need to remove anything that doesn't work in the

...vm ? llvm[3]: Compiling ClangASTNodesEmitter.cpp for Debug build In file included from /home/jmatai/Work/llvm2.9/llvm/final/tools/clang/utils/TableGen/ClangASTNodesEmitter.cpp:14: /home/jmatai/Work/llvm2.9/llvm/final/tools/clang/utils/TableGen/ClangASTNodesEmitter.h:17:43: error: llvm/TableGen/TableGenBackend.h: No such file or directory /home/jmatai/Work/llvm2.9/llvm/final/tools/clang/utils/TableGen/ClangASTNodesEmitter.h:18:34: error: llvm/TableGen/Record.h: No such file or directory In file included from /home/jmatai/Work/llvm2.9/llvm/final/tools/clang/utils/TableGen/ClangASTNodesEmitter.cpp:14:...

...ativePath="..\..\utils\TableGen\RegisterInfoEmitter.cpp"> > > </File> > > <File > > RelativePath="..\..\utils\TableGen\TableGen.cpp"> > > </File> > > <File > > RelativePath="..\..\utils\TableGen\TableGenBackend.cpp"> > > </File> > > </Filter> > > <Filter > > Name="Header Files" > > Filter="h;hpp;hxx;hm;inl;inc;xsd" > > UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"> > > <File...

...> <File > RelativePath="..\..\utils\TableGen\RegisterInfoEmitter.cpp"> > </File> > <File > RelativePath="..\..\utils\TableGen\TableGen.cpp"> > </File> > <File > RelativePath="..\..\utils\TableGen\TableGenBackend.cpp"> > </File> > </Filter> > <Filter > Name="Header Files" > Filter="h;hpp;hxx;hm;inl;inc;xsd" > UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"> > <File > RelativePath="..\..\u...

...ubtargetEmitter.cpp for Release+Asserts build llvm[2]: Compiling TGLexer.cpp for Release+Asserts build llvm[2]: Compiling TGParser.cpp for Release+Asserts build llvm[2]: Compiling TGValueTypes.cpp for Release+Asserts build llvm[2]: Compiling TableGen.cpp for Release+Asserts build llvm[2]: Compiling TableGenBackend.cpp for Release+Asserts build llvm[2]: Compiling X86DisassemblerTables.cpp for Release+Asserts build llvm[2]: Compiling X86RecognizableInstr.cpp for Release+Asserts build llvm[2]: Linking Release+Asserts executable tblgen (without symbols) llvm[2]: ======= Finished Linking Release+Asserts Executabl...

...elease+Asserts build > llvm[2]: Compiling TGLexer.cpp for Release+Asserts build > llvm[2]: Compiling TGParser.cpp for Release+Asserts build > llvm[2]: Compiling TGValueTypes.cpp for Release+Asserts build > llvm[2]: Compiling TableGen.cpp for Release+Asserts build > llvm[2]: Compiling TableGenBackend.cpp for Release+Asserts build > llvm[2]: Compiling X86DisassemblerTables.cpp for Release+Asserts build > llvm[2]: Compiling X86RecognizableInstr.cpp for Release+Asserts build > llvm[2]: Linking Release+Asserts executable tblgen (without symbols) > llvm[2]: ======= Finished Linking Relea...