search for: tgparser

...alue optimized out>, line=633, function=0x5abb20 "virtual llvm::RecTy* llvm::UnOpInit::getFieldType(const std::string&) const") at assert.c:81 #3 0x000000000050ddc8 in llvm::UnOpInit::getFieldType (this=0x850f00, FieldName=...) at Record.cpp:633 #4 0x0000000000543f64 in llvm::TGParser::ParseValue (this=0x7fffffffd480, CurRec=0x8511d0, ItemType=0x851540) at TGParser.cpp:1342 #5 0x0000000000544574 in llvm::TGParser::ParseValueList (this=0x7fffffffd480, CurRec=0x8511d0, ArgsRec=0x8510d0, EltTy=0x0) at TGParser.cpp:1405 #6 0x000000000053e520 in llvm::TGParser::ParseSubClassReferen...

...ut>, line=633, > function=0x5abb20 "virtual llvm::RecTy* llvm::UnOpInit::getFieldType(const std::string&) const") at assert.c:81 > #3 0x000000000050ddc8 in llvm::UnOpInit::getFieldType (this=0x850f00, FieldName=...) at Record.cpp:633 > #4 0x0000000000543f64 in llvm::TGParser::ParseValue (this=0x7fffffffd480, CurRec=0x8511d0, ItemType=0x851540) at TGParser.cpp:1342 > #5 0x0000000000544574 in llvm::TGParser::ParseValueList (this=0x7fffffffd480, CurRec=0x8511d0, ArgsRec=0x8510d0, EltTy=0x0) at TGParser.cpp:1405 > #6 0x000000000053e520 in llvm::TGParser::ParseSubCl...

...gt; function=0x5abb20 "virtual llvm::RecTy* > llvm::UnOpInit::getFieldType(const std::string&) const") at assert.c:81 > > #3 0x000000000050ddc8 in llvm::UnOpInit::getFieldType (this=0x850f00, > FieldName=...) at Record.cpp:633 > > #4 0x0000000000543f64 in llvm::TGParser::ParseValue > (this=0x7fffffffd480, CurRec=0x8511d0, ItemType=0x851540) at > TGParser.cpp:1342 > > #5 0x0000000000544574 in llvm::TGParser::ParseValueList > (this=0x7fffffffd480, CurRec=0x8511d0, ArgsRec=0x8510d0, EltTy=0x0) at > TGParser.cpp:1405 > > #6 0x000000000053e520...

Hi LLVMers, I found a bug in TGParser that is causing llvm-tblgen to crash on bad input. The reduced testcase is attached. The output follows: $ ./llvm-tblgen --version Low Level Virtual Machine (http://llvm.org/): LLVM version 3.1svn DEBUG build with assertions. Built Jan 20 2012 (15:46:08). Default target: x86_64-apple-darwi...

Hello everyone, I bring to discussion the necessity/design of a new type of smart pointer. r215176 and r217791 rise the problem, D5443 <http://reviews.llvm.org/D5443> is devoted to the solution. r215176 applies several temporary ugly fixes of memory leaks in TGParser.cpp which would be great to be refactored using smart pointers. D5443 <http://reviews.llvm.org/D5443> demonstrates how the solution with a certain type of smart pointer would look like (see changes in TGParser::ParseDef(), TGParser::InstantiateMulticlassDef() and TGParser::ParseSimpleValu...

...cpp" in one of the make files (didn't spend time to figure out why), following which CMake produced a nice working Visual Studio 2008 solution file. I opened this up in VS 2008 Express and everything seems to build properly except for the following errors: 1>c:\llvm\utils\tablegen\TGParser.h(69) : warning C4099: 'llvm::SubClassReference' : type name first seen using 'struct' now seen using 'class' 1> c:\llvm\utils\tablegen\TGParser.h(26) : see declaration of 'llvm::SubClassReference' 1>c:\llvm\utils\tablegen\Record.h(38) : warning C409...

...designed for here, in my experience, doesn't seem to come up often enough to justify a custom ADT - but the more general tool of sometimes-owning smart pointer seems common enough (& problematic enough) to warrant a generic data structure (and such a structure would also be appliable to the TGParser use case where this came up). I'd love to hear some more opinions, but maybe we're not going to get them... > > The main goal of the wrapper is to eliminate leaks like those in TGParser.cpp > - r215176 > <http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/TableGen/TGParser...

I've been trying to get llvm to compile under windows with the Intel C+ + 11.0.066 compiler without killing the compiler. I filed a bug report with Intel, and Intel says that their compiler has a problem with RecTy and Init being declared with "class" in utils \TableGen\TGParser.h but defined with "struct" in utils\TableGen \Record.h. The attached patch changes TGParser.h to use struct. -------------- next part -------------- A non-text attachment was scrubbed... Name: intel-patch.diff Type: application/octet-stream Size: 386 bytes Desc: not available URL: &l...

Seems to just be a byproduct of TGParser::AddSubClass() begin called twice. This means that TGParser::AddValue() is being called once for the "i" of each class, and the "last one wins". Not sure if it is intended, but this behavior seems to more-or-less "make sense". --Sean Silva On Mon, Jul 2, 2012 at 4:5...

...One thing I believe also bothers someone else. Say we have the following code snippet: bits<32> insnEncoding; let insnEncoding{15-12} = 0b0100; Can we write the let expression with range list like this, with the same meaning? let insnEncoding{12-15} = 0b0100; I take a look on TGParser::ParseRangePiece (lib/TableGen/TGParser.cpp), seems the answer is YES. Can anyone confirm this? Thanks. Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org...

Attached patch for removing for the first trivial RecordKeeper:: getAllDerivedDefinitions(...) dependency on the global RecordKeeper Records instance. The real work will be removing this dependency from the other Record.h classes/structs, and from TGParser. Thinking this would be implemented as some sort of context structure/class holding a RecordKeeper instance passed to TGParser which in turn would set this RecordKeeper instance on the various Record classes/ structures. Not sure about this yet. Free to direct if you wish. :-) I checked this with...

class one { int i = 0; } class two { int i = 1; } class multiple: one, two; This causes the first i to be ignored and the second i to replace it. This is a useful property if you want to specialize classes. But I don't know if it was intended to work that way or not. For example, if you have an instruction class with no patterns, you can merge it with one that defines the pattern

Hi Jakob, How is `FieldName`, which is a std::string, being passed as the third argument to SetValue on line 1848 of TGParser.cpp, which is declared as being an Init*? The nearly identical (FIXME) codepath in ParseDeclaration immediately puts the string into a StringInit, which makes sense, but how on earth is the std::string being passed in? This is really freaking me out. -- Sean Silva

...mple enough to understand and maintain, at least I believe so. [Why preprocessor?] I admit that a preprocessor is probably not the best solution. And we can implement for-loop without a preprocessor. The only reason I chose a preprocessor is because (I believe) this would add least changes to the TGParser.cpp. The TGParser.cpp as its current form parses and emits the results in one-pass. That means it would emit the for-loop body even before we are done parsing the entire for-loop. So I believe a non-preprocessor approach would require 2 passes. The first pass parses the input and generates a simp...

I made a simple edit to TGlexer.h, which is part of TableGen. Then, in Visual Studio, I asked it to build Tablegen. I got the following output: 1>------ Build started: Project: LLVMTableGen, Configuration: Release x64 ------ 1>Main.cpp 1>TGLexer.cpp 1>TGParser.cpp 1>LLVMTableGen.vcxproj -> D:\LLVM\Build\Release\lib\LLVMTableGen.lib ========== Build: 1 succeeded, 0 failed, 3 up-to-date, 0 skipped ========== Makes sense to me. But why doesn't it continue on and relink llvm-tblgen.exe? I spent about half an hour searching the interwebs, but all I...

On Oct 6, 2011, at 12:42 PM, David A. Greene wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: >> >>> For example, I want to be able to do this: >>> >>> defm MOVH : >>> vs1x_fps_binary_vv_node_rmonly< >>> 0x16, "movh", undef, 0, >>>

Not sure what you mean. I.OutOperandList == (outs CPU16Regs:$rx) I.InOperandList == (ins CPU16Regs:$ry, CPU16Regs:$rz) On 07/02/2012 09:26 PM, Sean Silva wrote: > I think you're missing the template args for `FRRR16_ins` in the first > argument. The switch in TGParser::ParseType() doesn't cover the case > of types with template args though... which makes me wonder what is > going on inside of TableGen to make `I.f` and `I.AsmString` valid... > > --Sean Silva > > On Mon, Jul 2, 2012 at 8:07 PM, reed kotler<rkotler at mips.com> wrote:...

.... Perhaps that's not worth it, however. I can live with this level of duplication. I would also like to replace #NAME# with a "real" Record field that is automatically added to def-type Records. This removes a lot of the hackiness of #NAME#. > [Why preprocessor?] > > The TGParser.cpp as its current form parses and emits the results in > one-pass. That means it would emit the for-loop body even before we > are done parsing the entire for-loop. It doesn't have to. I'm working on a for loop that is not preprocessor based. It uses the same technique as the mult...

...wing patch removes all global references to a RecordKeeper instance for the tblgen utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files were touched, the main change was to Record.h. The patch takes the simple approach of adding a RecordKeeper reference to TGParser, and any needed emitter helper classes. In addition, since some of the classes, and methods in Record reference the previously global RecordKeeper instance, I added another RecordKeeper reference to Record, along with such a typed argument to Record's constructor, and a corresponding factor...

...doesn't seem > to come up often enough to justify a custom ADT - but the more > general tool of sometimes-owning smart pointer seems common enough > (& problematic enough) to warrant a generic data structure (and > such a structure would also be appliable to the TGParser use case > where this came up). > David, could you, please, clarify the concept of the "maybe owning pointer"? > > I'd love to hear some more opinions, but maybe we're not going to > get them... > > > I strongly agree that the example here isn&...