| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
semantics (at least when removal is not needed) without the extra indirection/ownership complexity
Order matters for this container, it seems (using a forward_list and
replacing the original push_backs with emplace_fronts caused test
failures). I didn't look too deeply into why.
(& in retrospect, I might go back & change some of the forward_lists I
introduced to deques anyway - since most don't require removal, deque is
a more memory-friendly data structure (moderate locality while not
invalidating pointers))
llvm-svn: 222950
|
| |
|
|
|
|
| |
value in their container, removing the indirection
llvm-svn: 222949
|
| |
|
|
|
|
|
|
|
|
|
|
| |
vector<unique_ptr<T>>"
This reverts commit r222935 and its follow-up r222938 ("Push unique_ptr
a bit further through some APIs and simplify some cleanup"), since it
causes bot failures (at least on Darwin):
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/1391/
llvm-svn: 222943
|
| |
|
|
|
|
|
|
|
| |
Just avoid using std::map::emplace since it's not implemented in
libstdc++ 4.7.
Reapplies r222937, reverted in r222939.
llvm-svn: 222940
|
| |
|
|
|
|
|
|
|
| |
Seems libstdc++ on some buildbots is lacking std::map::emplace, which is
weird... reverting while I look into it.
This reverts commit r222937.
llvm-svn: 222939
|
| |
|
|
| |
llvm-svn: 222938
|
| |
|
|
|
|
|
|
|
|
|
| |
Pointers and references to map elements are never invalidated (except on
removal, which isn't used here) so there's no need for the indirection
unless there's polymorphism at work.
A little const correctness had to be fixed, since the indirection
allowed some benign const violations.
llvm-svn: 222937
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit r222632 (and follow-up r222636), which caused a host
of LNT failures on an internal bot. I'll respond to the commit on the
list with a reproduction of one of the failures.
Conflicts:
lib/Target/X86/X86TargetTransformInfo.cpp
llvm-svn: 222936
|
| |
|
|
|
|
| |
vector<unique_ptr<T>>
llvm-svn: 222935
|
| |
|
|
| |
llvm-svn: 222934
|
| |
|
|
|
|
|
|
| |
Since the elements were not polymorphic, the unique_ptr was only used to
avoid pointer invalidation on container resizes - might as well skip the
indirection and use a container with suitable invalidation semantics.
llvm-svn: 222931
|
| |
|
|
| |
llvm-svn: 222930
|
| |
|
|
| |
llvm-svn: 222929
|
| |
|
|
| |
llvm-svn: 222912
|
| |
|
|
| |
llvm-svn: 222909
|
| |
|
|
| |
llvm-svn: 222908
|
| |
|
|
|
|
| |
Mostly pulled from Rafael's r185678 commit message.
llvm-svn: 222855
|
| |
|
|
|
|
| |
Everyone should use hasSideEffects now.
llvm-svn: 222809
|
| |
|
|
|
|
| |
all marked isCodeGenOnly these days.
llvm-svn: 222783
|
| |
|
|
| |
llvm-svn: 222782
|
| |
|
|
| |
llvm-svn: 222781
|
| |
|
|
| |
llvm-svn: 222780
|
| |
|
|
| |
llvm-svn: 222779
|
| |
|
|
|
|
| |
AsmWriter output.
llvm-svn: 222650
|
| |
|
|
|
|
| |
to reduce total data size.
llvm-svn: 222643
|
| |
|
|
| |
llvm-svn: 222633
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduced new target-independent intrinsics in order to support masked vector loads and stores. The loop vectorizer optimizes loops containing conditional memory accesses by generating these intrinsics for existing targets AVX2 and AVX-512. The vectorizer asks the target about availability of masked vector loads and stores.
Added SDNodes for masked operations and lowering patterns for X86 code generator.
Examples:
<16 x i32> @llvm.masked.load.v16i32(i8* %addr, <16 x i32> %passthru, i32 4 /* align */, <16 x i1> %mask)
declare void @llvm.masked.store.v8f64(i8* %addr, <8 x double> %value, i32 4, <8 x i1> %mask)
Scalarizer for other targets (not AVX2/AVX-512) will be done in a separate patch.
http://reviews.llvm.org/D6191
llvm-svn: 222632
|
| |
|
|
|
|
| |
Primarily done by using SequenceToOffsetTable to reduce the register pressure set tables and then sizing the indices into the tables appropriately. Size a few other table entries based on content as well. Reduces X86RegisterInfo.o by ~9k.
llvm-svn: 222621
|
| |
|
|
|
|
| |
RegisterInfo output file.
llvm-svn: 222508
|
| |
|
|
| |
llvm-svn: 222411
|
| |
|
|
|
|
| |
output.
llvm-svn: 222410
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pair<iterator, bool>
This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.
This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...
llvm-svn: 222334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
llvm-svn: 222319
|
| |
|
|
|
|
| |
change. This saves us from rebuilding llvm-config each time we reconfigure.
llvm-svn: 222308
|
| |
|
|
|
|
|
|
|
|
|
|
| |
self-associative containers
StringSet is still a bit dodgy in that it exposes the raw iterator of
the StringMap parent, which exposes the weird detail that StringSet
actually has a 'value'... but anyway, this is useful for a handful of
clients that want to reference the newly inserted/persistent string data
in the StringSet/Map/Entry/thing.
llvm-svn: 222302
|
| |
|
|
|
|
|
|
|
|
|
|
| |
TreePattern's Tree member."
This reverts commit r222183.
Broke on the MSVC buildbots due to MSVC not producing default move
operations - I'd fix it immediately but just broke my build system a
bit, so backing out until I have a chance to get everything going again.
llvm-svn: 222187
|
| |
|
|
|
|
|
|
|
|
|
|
| |
TreePattern's Tree member.
The next step is to actually use unique_ptr in TreePatternNode's
Children vector. That will be more intrusive, and may not work,
depending on exactly how these things are handled (I have a bad
suspicion things are shared more than they should be, making this more
DAG than tree - but if it's really a tree, unique_ptr should suffice)
llvm-svn: 222183
|
| |
|
|
|
|
|
|
| |
reduce static table size and number of relocation entries.
Indices into the table are stored in each MCRegisterClass instead of a pointer. A new method, getRegClassName, is added to MCRegisterInfo and TargetRegisterInfo to lookup the string in the table.
llvm-svn: 222118
|
| |
|
|
| |
llvm-svn: 222046
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
based on instruction complexity
The order that tablegen fast-isel instruction code is generated is
currently based on the text of the predicate (using string
less-than). This patch changes this to instead use the instruction
complexity. Because the complexities are not unique a C++ multimap is
used instead of a map.
This fixes the problem where code with no predicate always comes out
first (the empty string always compares as less than all other
strings) thus making the code with predicates dead code. See the FMUL
code in PPCFastISel.cpp for an example. It also more closely matches
the normal codegen ordering. Some error checking in the tablegen
fast-isel code is fixed as well.
Patch by Bill Seurer.
llvm-svn: 222038
|
| |
|
|
|
|
|
|
|
|
| |
Build failed here:
http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/14629/steps/build_Lld/logs/stdio
So I'm taking a shot in the dark that MSVC (whatever version that is)
can't cope with nested name specifiers with a decltype prefix.
llvm-svn: 221931
|
| |
|
|
|
|
|
|
|
| |
CodeGenDAGPatterns::PatternFragments
We might be able to use unique_ptr to handle ownership of the
TreePatternNodes too - looking into that next.
llvm-svn: 221928
|
| |
|
|
|
|
|
| |
The underlying error function already uses a Twine,
and most of the uses build up strings.
llvm-svn: 221740
|
| |
|
|
|
|
| |
Base classes were storing a second copy.
llvm-svn: 221667
|
| |
|
|
| |
llvm-svn: 221221
|
| |
|
|
|
|
|
|
| |
Currently they are passed to tests of llvm itself, but not, for example, lld.
With this patch the options are visible in every test.
llvm-svn: 221198
|
| |
|
|
| |
llvm-svn: 221191
|
| |
|
|
|
|
|
| |
With this patch I can use asan to test the gold plugin without having
to build gold itself with asan.
llvm-svn: 221183
|
| |
|
|
|
|
|
|
|
| |
The problem is mostly that variadic output instruction
aren't handled, so it is rejected for having an inconsistent
number of operands, and then the right number of operands
isn't emitted.
llvm-svn: 221117
|
| |
|
|
| |
llvm-svn: 221116
|