search for: tablegened

Hello LLVM developers, Following some hints on this mailing list earlier this year on how to make clang faster than stock llvm.org builds I have implemented a script that builds a PGO optimized version of clang by following the guide here: http://llvm.org/docs/HowToBuildWithPGO.html This works great on macOS and Linux - we gained almost 15% in our project with this technique. I am now looking at

I had llvm 2.9 installed on ununtu. I tried to build clang but got following error. I have llvm 2.9 and clang is latest version ( I don't know, I got from svn). I am wondering is it because of version problem ? Does clang work with 2.9 llvm ? llvm[3]: Compiling ClangASTNodesEmitter.cpp for Debug build In file included from

Hi LLVM'ers When linking tblgen tool I get below error message on MinGW. I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. However, when rearranging library dbghelp to the end of the g++ line, tblgen gets linked. -------------------------- make[2]: Entering directory `/C/Projects/build/MinGW/llvm/utils/TableGen' Linking Debug executable tblgen /C/Projects/build/MinGW/llvm/mklib

On OS X 10.5.5 I get an error that ld doesn't support -export-dynamic: dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ ../src/configure --prefix=`pwd`/../install && make VERBOSE=1 ... dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ make VERBOSE=1 for dir in lib/System lib/Support utils lib/VMCore lib tools/llvm-config tools docs; do \ if [ ! -f

Hi, We are trying to enable LeakSanitizer on our asan/msan llvm bootstrap bot (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/). In clang itself there are two leaks (http://llvm.org/bugs/show_bug.cgi?id=18318, http://llvm-reviews.chandlerc.com/D2472) and one lsan-hostile feature (http://llvm.org/bugs/show_bug.cgi?id=18320), all of which are easy to fix. And there are also

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

Hi all, On my Fedora 10 x86-64 the current svn dies in the following way: /home/maurice/installation/llvm-dev/utils/TableGen/Debug/TGLexer.o: In function `llvm::TGLexer::getNextChar()': /home/maurice/installation/llvm-dev/utils/TableGen/TGLexer.cpp:71: undefined reference to `llvm::TGSourceMgr::FindBufferContainingLoc(llvm::TGLoc) const'

On Wed, Dec 25, 2013 at 9:38 PM, dblaikie at gmail.com <dblaikie at gmail.com> wrote: > Its generally been by design that tblgen leaks. Might be nice to fix one day > but it's been that way for a while now so don't expect it to be fixed soon. > > If thats the suppression mechanism of choice (I would've expected a build > flag option) for lsan, I'd say go for

I was confused by the lack of TableGen backends in the llvm/lib/tablegen directory until I stumbled upon the llvm/utils/tablegen directory. Could someone explain why TableGen is divided into these two directories? ---------------------------------------------------------------- Windfall Paul C. Anagnostopoulos ----------------------------------------------------------

Henrik Bach wrote: > Hi LLVM'ers > > When linking tblgen tool I get below error message on MinGW. > > I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. > > However, when rearranging library dbghelp to the end of the g++ > line, tblgen gets linked. It seems that the -L path options are specified before the LLVM libraries (libSystem and libsupport) are linked in.

Alright, this version works for me. Anything else that needs to be done? -Alex > On Oct 7, 2015, at 8:15 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake > index 452a728..cb06450 100644 > --- a/cmake/modules/TableGen.cmake > +++ b/cmake/modules/TableGen.cmake > @@ -70,6 +70,15 @@

Are multi-output patterns in TableGen supposed to work, or is that a known limitation in the current implementation? If I have TableGen code like the following... 1242 def SDTTestNode : SDTypeProfile<2, 1, [SDTCisSameAs<0, 1>]>; 1243 def TestNode : SDNode<"NVPTXISD::TestNode", SDTTestNode>; 1244 1245 def MyTestNode : NVPTXInst<(outs Int32Regs:$dst0,

This is the second in a series of occasional TableGen newsletters. The purpose is to inform the greater LLVM community of changes and enhancements to TableGen and its backends. * As announced previously, there are two new TableGen documents and three updated ones: TableGen Overview --- https://llvm.org/docs/TableGen/ TableGen Programmer's Reference ---

Hello, Neal > You may want to note that you need glibc-devel.i386 to build. Otherwise you > get error on /usr/include/gnu/stubs-32.h missing. Do you have pure 64 bit system? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

You may want to note that you need glibc-devel.i386 to build. Otherwise you get error on /usr/include/gnu/stubs-32.h missing.

It should probably be inside an `if(LLVM_USE_HOST_TOOLS)` block. That way the extra target and command won’t get added unless needed and CMake won’t spew dev warnings. Adding a target with a nonexistent dependency makes CMake dump a bunch of developer warnings. Other than that this looks good. Does it resolve the issue for you? -Chris > On Oct 7, 2015, at 4:09 PM, Alex Wang <aw1621107 at

On 7/13/2020 21:30, Thomas Lively via llvm-dev wrote: > Part of the problem is that ISel patterns are like their own DSL inside > the TableGen DSL, so keywords like "ins", "outs", and "ops" aren't > keywords at the TableGen level, but rather at the level of the ISel > system implemented with TableGen. Copying existing patterns and reading > the

Thanks for the info. Is this on someone's list of things to do? On Sun, Jan 6, 2013 at 7:41 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jan 4, 2013, at 9:52 AM, Justin Holewinski <justin.holewinski at gmail.com> > wrote: > > Are multi-output patterns in TableGen supposed to work, or is that a known > limitation in the current implementation? >

Looks good to me! I can commit this for you today. Thanks! -Chris > On Oct 19, 2015, at 2:40 PM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Looks like the LLVMSupport patch didn't get everything -- build failed in the > same way on libLLVMTableGen. Problem/solution looked the same as for > LLVMSupport, so just tweaked the previous patch, and

LGTM. I think it is totally reasonable to just disable LSan directly in tablegen at least for now. I would leave some comments on the disabling to clarify: 1) What it does, the reader may not have heard about LSan. 2) Some of the high-level information from this thread as pointers for anyone who wants to go and fix this some day. -Chandler On Wed, Dec 25, 2013 at 2:26 PM, Kostya Serebryany