aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/TableGen
AgeCommit message (Collapse)AuthorFilesLines
2014-12-12Clean up static analyzer warnings.Michael Ilseman1-1/+1
Clang's static analyzer found several potential cases of undefined behavior, use of un-initialized values, and potentially null pointer dereferences in tablegen, Support, MC, and ADT. This cleans them up with specific assertions on the assumptions of the code. llvm-svn: 224154
2014-12-11Use range-based for loops. NFCCraig Topper1-5/+2
llvm-svn: 224005
2014-12-11Make MultiClass::DefPrototypes own their Records to fix memory leaks.Craig Topper1-13/+8
llvm-svn: 223998
2014-12-11Replace std::map<K, V*> with std::map<K, std::unique_ptr<V>> to handle ↵Craig Topper2-6/+9
ownership and deletion of the values. Ideally we would store the MultiClasses by value directly in the maps, but I had some trouble with that before and this at least fixes the leak. llvm-svn: 223997
2014-11-30Revert r222957 "Replace std::map<K, V*> with std::map<K, V> to handle ↵Craig Topper2-12/+9
ownership and deletion of the values." Upon further review I think the MultiClass is being copied into the map instead of being moved due to the copy constructor on the nested Record type. This ultimately got exposed when the vector in DefPrototype vector was changed to hold unique_ptrs in another commit. This caused gcc 4.7 to fail due to the use of the copy constructor on unique_ptr with the error pointing back to one of the insert calls from this commit. Not sure why clang was able to build. This reverts commit 710cdf729f84b428bf41aa8d32dbdb35fff79fde. llvm-svn: 222971
2014-11-30Revert r222965 "Make MultiClass::DefPrototypes own their Records to fix ↵Hans Wennborg1-6/+6
memory leaks." The bots started failing with the error below. I suspect this revision was the cause. FAILED: /home/bb/bin/g++47 -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -O3 -DNDEBUG -Ilib/TableGen -I/home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen -Iinclude -I/home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include -fno-exceptions -fno-rtti -MMD -MT lib/TableGen/CMakeFiles/LLVMTableGen.dir/TGParser.cpp.o -MF "lib/TableGen/CMakeFiles/LLVMTableGen.dir/TGParser.cpp.o.d" -o lib/TableGen/CMakeFiles/LLVMTableGen.dir/TGParser.cpp.o -c /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.cpp In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_tempbuf.h:62:0, from /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_algo.h:64, from /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/algorithm:63, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/ADT/StringRef.h:13, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGLexer.h:17, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.h:17, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.cpp:14: /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_construct.h: In instantiation of 'void std::_Construct(_T1*, _Args&& ...) [with _T1 = std::unique_ptr<llvm::Record>; _Args = {const std::unique_ptr<llvm::Record, std::default_delete<llvm::Record> >&}]': /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_uninitialized.h:77:3: required from 'static _ForwardIterator std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator<const std::unique_ptr<llvm::Record>*, std::vector<std::unique_ptr<llvm::Record> > >; _ForwardIterator = std::unique_ptr<llvm::Record>*; bool _TrivialValueTypes = false]' /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_uninitialized.h:119:41: required from '_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator<const std::unique_ptr<llvm::Record>*, std::vector<std::unique_ptr<llvm::Record> > >; _ForwardIterator = std::unique_ptr<llvm::Record>*]' /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_uninitialized.h:260:63: required from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, std::allocator<_Tp>&) [with _InputIterator = __gnu_cxx::__normal_iterator<const std::unique_ptr<llvm::Record>*, std::vector<std::unique_ptr<llvm::Record> > >; _ForwardIterator = std::unique_ptr<llvm::Record>*; _Tp = std::unique_ptr<llvm::Record>]' /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:310:9: required from 'std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp = std::unique_ptr<llvm::Record>; _Alloc = std::allocator<std::unique_ptr<llvm::Record> >]' /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/TableGen/Record.h:1664:8: required from 'constexpr std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = std::basic_string<char>&; _U2 = llvm::MultiClass; <template-parameter-2-3> = void; _T1 = std::basic_string<char>; _T2 = llvm::MultiClass]' /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:273:72: required from 'constexpr std::pair<typename std::__decay_and_strip<_T1>::__type, typename std::__decay_and_strip<_T2>::__type> std::make_pair(_T1&&, _T2&&) [with _T1 = std::basic_string<char>&; _T2 = llvm::MultiClass; typename std::__decay_and_strip<_T2>::__type = llvm::MultiClass; typename std::__decay_and_strip<_T1>::__type = std::basic_string<char>]' /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.cpp:2295:78: required from here /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_construct.h:77:7: error: use of deleted function 'std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = llvm::Record; _Dp = std::default_delete<llvm::Record>]' In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/memory:86:0, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/ADT/STLExtras.h:25, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:14, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/Support/SourceMgr.h:19, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.h:19, from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.cpp:14: /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/unique_ptr.h:262:7: error: declared here ninja: build stopped: subcommand failed. llvm-svn: 222970
2014-11-30Qualify one more make_unique call.Hans Wennborg1-2/+2
The previous patch had effect, but missed this one. It seems MSVC gets ADL-confused by the calls where the first argument is a function call? llvm-svn: 222968
2014-11-30Speculatively qualify some llvm::make_unique calls trying to please MSVCHans Wennborg1-4/+4
It was failing with this kind of error: C:\b\build\slave\CrWinClang\build\src\third_party\llvm\lib\TableGen\TGParser.cpp(1243) : error C2668: 'llvm::make_unique' : ambiguous call to overloaded function C:\b\build\slave\CrWinClang\build\src\third_party\llvm\include\llvm/ADT/STLExtras.h(408): could be 'std::unique_ptr<llvm::Record,std::default_delete<_Ty>> llvm::make_unique<llvm::Record,std::string,llvm::SMLoc&,llvm::RecordKeeper&,bool>(std::string &&,llvm::SMLoc &,llvm::RecordKeeper &,bool &&)' with [ _Ty=llvm::Record ] C:\b\depot_tools\win_toolchain\vs2013_files\win8sdk\bin\..\..\VC\include\memory(1637): or 'std::unique_ptr<llvm::Record,std::default_delete<_Ty>> std::make_unique<llvm::Record,std::string,llvm::SMLoc&,llvm::RecordKeeper&,bool>(std::string &&,llvm::SMLoc &,llvm::RecordKeeper &,bool &&)' [found using argument-dependent lookup] with [ _Ty=llvm::Record ] while trying to match the argument list '(std::string, llvm::SMLoc, llvm::RecordKeeper, bool)' llvm-svn: 222967
2014-11-30Use an unsigned type because there seems to be no reason for it to be signed.Craig Topper1-1/+1
llvm-svn: 222966
2014-11-30Make MultiClass::DefPrototypes own their Records to fix memory leaks.Craig Topper1-6/+6
llvm-svn: 222965
2014-11-29Replace std::map<K, V*> with std::map<K, V> to handle ownership and deletion ↵Craig Topper2-9/+12
of the values. llvm-svn: 222957
2014-11-29Remove 'else' after 'return'. Fix formatting of a 'switch' statement.Craig Topper1-12/+11
llvm-svn: 222955
2014-11-29Make RecordKeeper::addClass/addDef take unique_ptrs instead of creating one ↵Craig Topper1-6/+8
internally. llvm-svn: 222948
2014-11-29Use unique_ptr to remove some explicit deletes on some error case returns. ↵Craig Topper1-68/+46
At least one spot of weird ownership passing that needs some future cleanup. llvm-svn: 222947
2014-10-03Eliminate some deep std::vector copies. NFC.Benjamin Kramer1-1/+1
llvm-svn: 218999
2014-09-25Refactoring: raw pointer -> unique_ptrAnton Yartsev1-5/+3
llvm-svn: 218462
2014-09-16[TableGen] Fully resolve class-instance values before defs in multiclassesAdam Nemet1-0/+9
By class-instance values I mean 'Class<Arg>' in 'Class<Arg>.Field' or in 'Other<Class<Arg>>' (syntactically s SimpleValue). This is to differentiate from unnamed/anonymous record definitions (syntactically an ObjectBody) which are not affected by this change. Consider the testcase: class Struct<int i> { int I = !shl(i, 1); int J = !shl(I, 1); } class Class<Struct s> { int Class_J = s.J; } multiclass MultiClass<int i> { def Def : Class<Struct<i>>; } defm Defm : MultiClass<2>; Before this fix, DefmDef.Class_J yields !shl(I, 1) instead of 8. This is the sequence of events. We start with this: multiclass MultiClass<int i> { def Def : Class<Struct<i>>; } During ParseDef the anonymous object for the class-instance value is created: multiclass Multiclass<int i> { def anonymous_0 : Struct<i>; def Def : Class<NAME#anonymous_0>; } Then class Struct<i> is added to anonymous_0. Also Class<NAME#anonymous_0> is added to Def: multiclass Multiclass<int i> { def anonymous_0 { int I = !shl(i, 1); int J = !shl(I, 1); } def Def { int Class_J = NAME#anonymous_0.J; } } So far so good but then we move on to instantiating this in the defm by substituting the template arg 'i'. This is how the anonymous prototype looks after fully instantiating. defm Defm = { def Defmanonymous_0 { int I = 4; int J = !shl(I, 1); } Note that we only resolved the reference to the template arg. The non-template-arg reference in 'J' has not been resolved yet. Then we go on to instantiating the Def prototype: def DefmDef { int Class_J = NAME#anonymous_0.J; } Which is resolved to Defmanonymous_0.J and then to !shl(I, 1). When we fully resolve each record in a defm, Defmanonymous_0.J does get set to 8 but that's too late for its use. The patch adds a new attribute to the Record class that indicates that this def is actually a class-instance value that may be *used* by other defs in a multiclass. (This is unlike regular defs which don't reference each other and thus can be resolved indepedently.) They are then fully resolved before the other defs while the multiclass is instantiated. I added vg_leak to the new test. I am not sure if this is necessary but I don't think I have a way to test it. I can also check in without the XFAIL and let the bots test this part. Also tested that X86.td.expanded and AAarch64.td.expanded were unchange before and after this change. (This issue triggering this problem is a WIP patch.) Part of <rdar://problem/17688758> llvm-svn: 217886
2014-08-29Comment only: Annotate loop as per mailing list discussionJean-Luc Duprat1-0/+3
llvm-svn: 216798
2014-08-29Tablegen fixes for new syntax when initializing bits from variables.Jean-Luc Duprat1-0/+9
Followup to r215086. llvm-svn: 216757
2014-08-25Modernize raw_fd_ostream's constructor a bit.Rafael Espindola1-10/+10
Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error. A create static method would be even better, but this patch is already a bit too big. llvm-svn: 216393
2014-08-24TableGen: unique_ptr-ify RecordKeeperDylan Noblesmith1-1/+1
llvm-svn: 216350
2014-08-24TableGen: delete no-op codeDylan Noblesmith1-7/+0
This does nothing but remove the Record from the map, and then re-add it, without actually changing it in between. The Record's Name used to be changed before re-adding it when the code was first committed in r137232, but the name-changing lines were removed in r142510, and since then this code seems to do nothing. This was also the only caller of removeClass or removeDef, so now RecordKeeper owns its Records unconditionally, and could be unique_ptr-ified. llvm-svn: 216349
2014-08-24TableGen: use auto and for-rangeDylan Noblesmith1-12/+9
llvm-svn: 216348
2014-08-21Explicitly pass ownership of the MemoryBuffer to AddNewSourceBuffer using ↵David Blaikie1-2/+1
std::unique_ptr llvm-svn: 216223
2014-08-13Canonicalize header guards into a common format.Benjamin Kramer2-4/+4
Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
2014-08-08[tablegen] - Eliminate memory leaks in TGParser.cppAnton Yartsev1-4/+26
Ugly solution indicating that a refactoring is necessary to get the ownership under control. llvm-svn: 215176
2014-08-07Silencing an MSVC C4334 warning ('<<' : result of 32-bit shift implicitly ↵Aaron Ballman1-1/+1
converted to 64 bits (was 64-bit shift intended?)). No functional changes intended. llvm-svn: 215100
2014-08-07Update BitRecTy::convertValue to allow if expressions with bit values on ↵Pete Cooper1-0/+10
both sides of the if llvm-svn: 215087
2014-08-07Change the { } expression in tablegen to accept sized binary literals which ↵Pete Cooper1-2/+13
are not just 0 and 1. It also allows nested { } expressions, as now that they are sized, we can merge pull bits from the nested value. In the current behaviour, everything in { } must have been convertible to a single bit. However, now that binary literals are sized, its useful to be able to initialize a range of bits. So, for example, its now possible to do bits<8> x = { 0, 1, { 0b1001 }, 0, 0b0 } llvm-svn: 215086
2014-08-07Change TableGen so that binary literals such as 0b001 are now sized.Pete Cooper3-1/+19
Instead of these becoming an integer literal internally, they now become bits<n> values. Prior to this change, 0b001 was 1 bit long. This is confusing as clearly the user gave 3 bits. This new type holds both the literal value and the size, and so can ensure sizes match on initializers. For example, this used to be legal bits<1> x = 0b00; but now it must be written as bits<2> x = 0b00; llvm-svn: 215084
2014-08-07TableGen: Change { } to only accept bits<n> entries when n == 1.Pete Cooper1-1/+4
Prior to this change, it was legal to do something like bits<2> opc = { 0, 1 }; bits<2> opc2 = { 1, 0 }; bits<2> a = { opc, opc2 }; This involved silently dropping bits from opc and opc2 which is very hard to debug. Now the above test would be an error. Having tested with an assert, none of LLVM/clang was relying on this behaviour. Thanks to Adam Nemet for the above test. llvm-svn: 215083
2014-08-05Allow binary and for tblgen math.Joerg Sonnenberger4-2/+9
llvm-svn: 214851
2014-07-31Don't fail tablegen immediately after failing to set a value.Pete Cooper1-1/+4
Instead allow the variable to be declared, but don't attach an initializer. This allows more than a single error to be emitted before we exit. Test case to follow soon in another patch. llvm-svn: 214375
2014-07-31Add a better error message when failing to assign one tablegen value to anotherPete Cooper1-1/+8
This is currently for assigning from one bit init to another. It can easily be extended to other types. Test to follow soon in another patch. llvm-svn: 214374
2014-07-17[TableGen] Allow shift operators to take bits<n>Adam Nemet1-2/+4
Convert the operand to int if possible, i.e. if the value is properly initialized. (I suppose there is further room for improvement here to also peform the shift if the uninitialized bits are shifted out.) With this little change we can now compute the scaling factor for compressed displacement with pure tablegen code in the X86 backend. This is useful because both the X86-disassembler-specific part of tablegen and the assembler need this and TD is the natural sharing place. The patch also adds the missing documentation for the shift and add operator. llvm-svn: 213277
2014-07-06Update the MemoryBuffer API to use ErrorOr.Rafael Espindola1-5/+6
llvm-svn: 212405
2014-07-06This only needs a StringRef.Rafael Espindola2-11/+11
llvm-svn: 212402
2014-07-06SourceMgr: make valid buffer IDs start from oneAlp Toker2-3/+3
Use 0 for the invalid buffer instead of -1/~0 and switch to unsigned representation to enable more idiomatic usage. Also introduce a trivial SourceMgr::getMainFileID() instead of hard-coding 0/1 to identify the main file. llvm-svn: 212398
2014-06-26Revert "Introduce a string_ostream string builder facilty"Alp Toker2-6/+8
Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
2014-06-26Introduce a string_ostream string builder faciltyAlp Toker2-8/+6
string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
2014-06-19Convert some assert(0) to llvm_unreachable or fold an 'if' condition into ↵Craig Topper1-8/+2
the assert. llvm-svn: 211254
2014-06-17Move SetTheory from utils/TableGen into lib/TableGen so Clang can use it.James Molloy2-0/+324
llvm-svn: 211100
2014-06-13Remove 'using std::errro_code' from lib.Rafael Espindola1-3/+1
llvm-svn: 210871
2014-06-12Don't use 'using std::error_code' in include/llvm.Rafael Espindola1-0/+1
This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12Remove system_error.h.Rafael Espindola1-1/+1
This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
2014-06-10Fix error in tablegen when either operand of !if is an empty list.Matt Arsenault2-7/+9
!if([Something], []) would error with "No type for list". llvm-svn: 210572
2014-06-10Anonymous definitions in foreach blocks triggered a 'def already exists'Artyom Skrobov1-2/+7
llvm-svn: 210526
2014-05-31Fix typos in tablegen error messagesMatt Arsenault1-3/+3
llvm-svn: 209968
2014-05-21[modules] Add module maps for LLVM. These are not quite ready for prime-timeRichard Smith1-0/+1
yet, but only a few more Clang patches need to land. (I have 'ninja check' passing locally.) llvm-svn: 209269
2014-05-08Use a vector of unique_ptrs to fix a memory leak introduced in r208179.Daniel Sanders1-2/+2
Also removed an inaccurate comment that stated that a DenseMap was used as storage for the ListInit*'s. It's currently using a FoldingSet. I expect there's a better way to fix this but I haven't found it yet. FoldingSet is incompatible with the Pool template and I'm not sure if FoldingSet can be safely replaced with a DenseMap of computed FoldingSetID's to ListInit*'s. llvm-svn: 208293
generated by cgit v1.1 at 2025-10-18 12:26:08 +0000