They weren't used often enough to justify having two different interfaces. Push the responsiblity of creating a StringInit up to the caller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304388 91177308-0d34-0410-b5e6-96231b3b80d8
Internally both these methods just return the result of getValue on either a StringInit or a CodeInit object. In both cases this returns a StringRef pointing to a string allocated in the BumpPtrAllocator so its not going anywhere. So we can just pass that StringRef along.
This is a fairly naive patch that targets just the build failures caused by this change. There's additional work that can be done to avoid creating std::string at call sites that still think getValueAsString returns a std::string. I'll try to clean those up in future patches.
Differential Revision: https://reviews.llvm.org/D33710
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304325 91177308-0d34-0410-b5e6-96231b3b80d8
DagInits are allocated in a BumpPtrAllocator so they are never destructed. This means the destructor for the SmallVector never runs.
To fix this we now allocate the vectors in the BumpPtrAllocator too using TrailingObjects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304077 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As far as instruction selection is concerned, all three appear to be same thing.
Support for these operands is experimental since AArch64 doesn't make use
of them and the in-tree targets that do use them (AMDGPU for
OperandWithDefaultOps, AMDGPU/ARM/Hexagon/Lanai for PredicateOperand, and ARM
for OperandWithDefaultOps) are not using tablegen-erated GlobalISel yet.
Reviewers: rovka, aditya_nandakumar, t.p.northover, qcolombet, ab
Reviewed By: rovka
Subscribers: inglorion, aemerson, rengolin, mehdi_amini, dberris, kristof.beyls, igorb, tpr, llvm-commits
Differential Revision: https://reviews.llvm.org/D31135
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@300037 91177308-0d34-0410-b5e6-96231b3b80d8
We had various variants of defining dump() functions in LLVM. Normalize
them (this should just consistently implement the things discussed in
http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html
For reference:
- Public headers should just declare the dump() method but not use
LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
- The definition of a dump method should look like this:
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void MyClass::dump() {
// print stuff to dbgs()...
}
#endif
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293359 91177308-0d34-0410-b5e6-96231b3b80d8
This may seem unusual, but makes most debug tblgen builds ~10% faster.
Usually we wouldn't care about speed that much in debug builds, but for
tblgen that also translates into build time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288652 91177308-0d34-0410-b5e6-96231b3b80d8
This forces the code to call StringInit::get on the string early and
avoids storing duplicates in std::string and sometimes allows pointer
comparisons instead of string comparisons.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288642 91177308-0d34-0410-b5e6-96231b3b80d8
All these records are internalized and will live until exit. This makes
them perfect candidates for a fast BumpPtrAllocator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288613 91177308-0d34-0410-b5e6-96231b3b80d8
This avoid an extra construction of a std::string (and a heap
allocation) when the caller only has a StringRef but no std::string at
hand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288610 91177308-0d34-0410-b5e6-96231b3b80d8
The way the named arguments for various system instructions are handled at the
moment has a few problems:
- Large-scale duplication between AArch64BaseInfo.h and AArch64BaseInfo.cpp
- That weird Mapping class that I have no idea what I was on when I thought
it was a good idea.
- Searches are performed linearly through the entire list.
- We print absolutely all registers in upper-case, even though some are
canonically mixed case (SPSel for example).
- The ARM ARM specifies sysregs in terms of 5 fields, but those are relegated
to comments in our implementation, with a slightly opaque hex value
indicating the canonical encoding LLVM will use.
This adds a new TableGen backend to produce efficiently searchable tables, and
switches AArch64 over to using that infrastructure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274576 91177308-0d34-0410-b5e6-96231b3b80d8
It's being immediately converted to a "string", but being able to tell what
type the field was originally can be useful in backends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274575 91177308-0d34-0410-b5e6-96231b3b80d8
Debug iterators are valuable so we don't want to turn them off
completely. However, llvm-tblgen is critical to build speed, so we can
skip them here.
Regenerating X86GenSubtargetInfo.inc in a clang-cl self-host debug build
now takes 39s instead of 1m29s.
Helps PR28222
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274288 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds a reserve call to an expensive function
(`llvm::LoadIntrinsics`), and may fix a few other low hanging
performance fruit (I've put them in comments for now, so we can
discuss).
**Motivation:**
As I'm sure other developers do, when I build LLVM, I build the entire
project with the same config (`Debug`, `MinSizeRel`, `Release`, or
`RelWithDebInfo`). However, the `Debug` config also builds llvm-tblgen
in `Debug` mode. Later build steps that run llvm-tblgen then can
actually be the slowest steps in the entire build. Nobody likes slow
builds.
Reviewers: rnk, dblaikie
Differential Revision: http://reviews.llvm.org/D16832
Patch by Alexander G. Riccio
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259683 91177308-0d34-0410-b5e6-96231b3b80d8
This brings the compile time of Function.cpp from ~40s down to ~4s for
me locally. It also shaves off about 400KB of object file size in a
release+asserts build.
I also realized that the AMDGPU backend does not have any GCC builtin
names to match, so the extra lookup was a no-op. I removed it to silence
a zero-length string table array warning. There should be no functional
change here.
This change really ends the story of PR11951.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258897 91177308-0d34-0410-b5e6-96231b3b80d8
Except the changes that defined virtual destructors as =default, because that
ran into problems with GCC 4.7 and overriding methods that weren't noexcept.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247298 91177308-0d34-0410-b5e6-96231b3b80d8
