Reid Kleckner [Thu, 14 Apr 2016 21:03:38 +0000 (21:03 +0000)]
In vector comparisons, handle scalar LHS just as we handle scalar RHS
Summary: Fixes PR27258
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19123
llvm-svn: 266366
Mehdi Amini [Thu, 14 Apr 2016 20:53:39 +0000 (20:53 +0000)]
Do not use llvm::getGlobalContext(), trying to nuke it from LLVM
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266365
Rafael Espindola [Thu, 14 Apr 2016 20:42:43 +0000 (20:42 +0000)]
Specialize the symbol table data structure a bit.
We never need to iterate over the K,V pairs, so we can avoid copying the
key as MapVector does.
This is a small speedup on most benchmarks.
llvm-svn: 266364
Renato Golin [Thu, 14 Apr 2016 20:42:18 +0000 (20:42 +0000)]
[ARM] Adding IEEE-754 SIMD detection to loop vectorizer
Some SIMD implementations are not IEEE-754 compliant, for example ARM's NEON.
This patch teaches the loop vectorizer to only allow transformations of loops
that either contain no floating-point operations or have enough allowance
flags supporting lack of precision (ex. -ffast-math, Darwin).
For that, the target description now has a method which tells us if the
vectorizer is allowed to handle FP math without falling into unsafe
representations, plus a check on every FP instruction in the candidate loop
to check for the safety flags.
This commit makes LLVM behave like GCC with respect to ARM NEON support, but
it stops short of fixing the underlying problem: sub-normals. Neither GCC
nor LLVM have a flag for allowing sub-normal operations. Before this patch,
GCC only allows it using unsafe-math flags and LLVM allows it by default with
no way to turn it off (short of not using NEON at all).
As a first step, we push this change to make it safe and in sync with GCC.
The second step is to discuss a new sub-normal's flag on both communitues
and come up with a common solution. The third step is to improve the FastMath
flags in LLVM to encode sub-normals and use those flags to restrict NEON FP.
Fixes PR16275.
llvm-svn: 266363
Sanjay Patel [Thu, 14 Apr 2016 20:17:40 +0000 (20:17 +0000)]
[InstCombine] remove constant by inverting compare + logic (PR27105)
https://llvm.org/bugs/show_bug.cgi?id=27105
We can check if all bits outside of a constant mask are set with a
single constant.
As noted in the bug report, although this form should be considered the
canonical IR, backends may want to transform this into an 'andn' / 'andc'
comparison against zero because that could be a single machine instruction.
Differential Revision: http://reviews.llvm.org/D18842
llvm-svn: 266362
Greg Clayton [Thu, 14 Apr 2016 20:05:21 +0000 (20:05 +0000)]
Fix Xcode project after recent s390x changes.
llvm-svn: 266361
Dehao Chen [Thu, 14 Apr 2016 19:46:38 +0000 (19:46 +0000)]
Fix null pointer access for discriminator assignment.
Summary: This fixes the buildbot failure.
Reviewers: dnovillo, davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19129
llvm-svn: 266360
Richard Smith [Thu, 14 Apr 2016 19:45:19 +0000 (19:45 +0000)]
Make this code less brittle. The benefits of a fixed-size array aren't worth the maintenance cost.
llvm-svn: 266359
Aaron Ballman [Thu, 14 Apr 2016 19:28:13 +0000 (19:28 +0000)]
Add support for type aliases to modernize-redundant-void-arg.cpp
Patch by Clement Courbet.
llvm-svn: 266358
Rafael Espindola [Thu, 14 Apr 2016 19:17:16 +0000 (19:17 +0000)]
Hash symbol names only once per global SymbolBody.
The DenseMap doesn't store hash results. This means that when it is
resized it has to recompute them.
This patch is a small hack that wraps the StringRef in a struct that
remembers the hash value. That way we can be sure it is only hashed
once.
llvm-svn: 266357
Tom Stellard [Thu, 14 Apr 2016 19:09:28 +0000 (19:09 +0000)]
AMDGPU: Add skeleton GlobalIsel implementation
Summary:
This adds the necessary target code to be able to run the ir translator.
Lowering function arguments and returns is a nop and there is no support
for RegBankSelect.
Reviewers: arsenm, qcolombet
Subscribers: arsenm, joker.eph, vkalintiris, llvm-commits
Differential Revision: http://reviews.llvm.org/D19077
llvm-svn: 266356
Rafael Espindola [Thu, 14 Apr 2016 18:39:44 +0000 (18:39 +0000)]
Simplify handling of size relocations. NFC.
llvm-svn: 266355
Dehao Chen [Thu, 14 Apr 2016 18:37:18 +0000 (18:37 +0000)]
Update discriminator assignment algorithm to handle nested call correctly.
Summary: Add discriminator for nested call correctly.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19127
llvm-svn: 266354
Richard Smith [Thu, 14 Apr 2016 18:32:54 +0000 (18:32 +0000)]
Fix off-by-one error in worst-case number of offsets needed for an AST record.
llvm-svn: 266353
Ulrich Weigand [Thu, 14 Apr 2016 18:31:12 +0000 (18:31 +0000)]
Fix regression in gnu_libstdcpp.py introduced by r266313
CreateChildAtOffset needs a byte offset, not an element number.
llvm-svn: 266352
Reid Kleckner [Thu, 14 Apr 2016 18:29:59 +0000 (18:29 +0000)]
Sink DI metadata usage out of MachineInstr.h and MachineInstrBuilder.h
MachineInstr.h and MachineInstrBuilder.h are very popular headers,
widely included across all LLVM backends. It turns out that there only a
handful of TUs that actually care about DI operands on MachineInstrs.
After this change, touching DebugInfoMetadata.h and rebuilding llc only
needs 112 actions instead of 542.
llvm-svn: 266351
Davide Italiano [Thu, 14 Apr 2016 18:07:32 +0000 (18:07 +0000)]
[ValueMapper] Range-loopify to improve readability. NFC.
llvm-svn: 266350
Jacques Pienaar [Thu, 14 Apr 2016 17:59:22 +0000 (17:59 +0000)]
[lanai] Add custom lowering for SRL_PARTS i32.
llvm-svn: 266349
Tom Stellard [Thu, 14 Apr 2016 17:45:38 +0000 (17:45 +0000)]
[GlobalISel] Move GISelAccessor class into public headers
Reviewers: qcolombet
Subscribers: joker.eph, vkalintiris, llvm-commits
Differential Revision: http://reviews.llvm.org/D19120
llvm-svn: 266348
Nicolai Haehnle [Thu, 14 Apr 2016 17:42:47 +0000 (17:42 +0000)]
[DivergenceAnalysis] Treat PHI with incoming undef as constant
Summary:
If a PHI has an incoming undef, we can pretend that it is equal to one
non-undef, non-self incoming value.
This is particularly relevant in combination with the StructurizeCFG
pass, which introduces PHI nodes with undefs. Previously, this lead to
branch conditions that were uniform before StructurizeCFG to become
non-uniform afterwards, which confused the SIAnnotateControlFlow
pass.
This fixes a crash when Mesa radeonsi compiles a shader from
dEQP-GLES3.functional.shaders.switch.switch_in_for_loop_dynamic_vertex
Reviewers: arsenm, tstellarAMD, jingyue
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19013
llvm-svn: 266347
Nicolai Haehnle [Thu, 14 Apr 2016 17:42:35 +0000 (17:42 +0000)]
[StructurizeCFG] Annotate branches that were treated as uniform
Summary:
This fully solves the problem where the StructurizeCFG pass does not
consider the same branches as uniform as the SIAnnotateControlFlow pass.
The patch in D19013 helps with this problem, but is not sufficient
(and, interestingly, causes a "regression" with one of the existing
test cases).
No tests included here, because tests in D19013 already cover this.
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D19018
llvm-svn: 266346
Nicolai Haehnle [Thu, 14 Apr 2016 17:42:29 +0000 (17:42 +0000)]
AMDGPU: Remove SIFixSGPRLiveRanges pass
Summary:
This pass is unnecessary and overly conservative. It was motivated by
situations like
def %vreg0:SGPR_32
...
if-block:
..
def %vreg1:SGPR_32
...
else-block:
...
use %vreg0:SGPR_32
...
and similar situations with uses after the non-uniform control flow, where
we are not allowed to assign %vreg0 and %vreg1 to the same physical register,
even though in the original, thread/workitem-based CFG, it looks like the
live ranges of these registers do not overlap.
However, by the time register allocation runs, we have moved to a wave-based
CFG that accurately represents the fact that the wave may run through both
the if- and the else-block. So the live ranges of %vreg0 and %vreg1 already
overlap even without the SIFixSGPRLiveRanges pass.
In addition to proving this change correct, I have tested it with Piglit
and a small number of other tests.
Reviewers: arsenm, tstellarAMD
Subscribers: MatzeB, arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D19041
llvm-svn: 266345
Nicolai Haehnle [Thu, 14 Apr 2016 17:42:18 +0000 (17:42 +0000)]
AMDGPU: change a redundant if () to an assert(). NFC
Summary:
I've been carrying this change around with me for a while, because the if ()
managed to confuse me while following the code. All callers ensure that the
assertion holds.
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D19042
llvm-svn: 266344
Ulrich Weigand [Thu, 14 Apr 2016 17:36:41 +0000 (17:36 +0000)]
Disable LinuxCoreTestCase.test_s390x
This seems to hang on non-s390x hosts. Disable for now to get the build
bots going again.
llvm-svn: 266343
Tom Stellard [Thu, 14 Apr 2016 17:23:33 +0000 (17:23 +0000)]
[GlobalISel] Coding style and whitespace fixes
Reviewers: qcolombet
Subscribers: joker.eph, llvm-commits, vkalintiris
Differential Revision: http://reviews.llvm.org/D19119
llvm-svn: 266342
Ulrich Weigand [Thu, 14 Apr 2016 17:22:18 +0000 (17:22 +0000)]
Revert r266311 - Fix usage of APInt.getRawData for big-endian systems
Try to get 32-bit build bots running again.
llvm-svn: 266341
George Rimar [Thu, 14 Apr 2016 17:05:56 +0000 (17:05 +0000)]
Move variables closer to code scopes that uses them. NFC.
llvm-svn: 266340
Tim Northover [Thu, 14 Apr 2016 17:03:29 +0000 (17:03 +0000)]
AArch64: expand cmpxchg after regalloc at -O0.
FastRegAlloc works only at the basic-block level and spills all live-out
registers. Unfortunately for a stack-based cmpxchg near the spill slots, this
can perpetually clear the exclusive monitor, which means the cmpxchg will never
succeed.
I believe the only way to handle this within LLVM is by expanding the loop
post-regalloc. We don't want this in general because it severely limits the
optimisations that can be done, so we limit this to -O0 compilations.
It's an ugly hack, and about the one good point in the whole mess is that we
can treat all cmpxchg operations in the most naive way possible (seq_cst, no
clrex faff) without affecting correctness.
Should fix PR25526.
llvm-svn: 266339
Jacques Pienaar [Thu, 14 Apr 2016 16:47:42 +0000 (16:47 +0000)]
[lanai] Add areMemAccessesTriviallyDisjoint, getMemOpBaseRegImmOfs and getMemOpBaseRegImmOfsWidth.
Summary: Add getMemOpBaseRegImmOfsWidth to enable determining independence during MiSched.
Reviewers: eliben, majnemer
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18903
llvm-svn: 266338
Tom Stellard [Thu, 14 Apr 2016 16:27:07 +0000 (16:27 +0000)]
AMDGPU: allow specifying a workgroup size that needs to fit in a compute unit
Summary:
For GL_ARB_compute_shader we need to support workgroup sizes of at least 1024. However, if we want to allow large workgroup sizes, we may need to use less registers, as we have to run more waves per SIMD.
This patch adds an attribute to specify the maximum work group size the compiled program needs to support. It defaults, to 256, as that has no wave restrictions.
Reducing the number of registers available is done similarly to how the registers were reserved for chips with the sgpr init bug.
Reviewers: mareko, arsenm, tstellarAMD, nhaehnle
Subscribers: FireBurn, kerberizer, llvm-commits, arsenm
Differential Revision: http://reviews.llvm.org/D18340
Patch By: Bas Nieuwenhuizen
llvm-svn: 266337
Tom Stellard [Thu, 14 Apr 2016 16:27:03 +0000 (16:27 +0000)]
AMDGPU/SI: Use the correct scratch wave offset register for shaders.
Summary:
The code previously always used s1 as it was using the user + system SGPR
information for compute kernels. This is incorrect for Mesa shaders though,
The register should be the next SGPR after all user and system SGPR's.
We use that Mesa adds arguments for all input and system SGPR's and
take the next available SGPR for the scratch wave offset register.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewers: mareko, arsenm, nhaehnle, tstellarAMD
Subscribers: qcolombet, arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18941
Patch By: Bas Nieuwenhuizen
llvm-svn: 266336
Betul Buyukkurt [Thu, 14 Apr 2016 16:25:45 +0000 (16:25 +0000)]
[PGO] Do not attach VP metadata if value count at site is 0 [NFC]
llvm-svn: 266335
Silviu Baranga [Thu, 14 Apr 2016 16:08:45 +0000 (16:08 +0000)]
[SCEV][LAA] Add tests for SCEV expression transformations performed during LAA
Summary:
Add a print method to Predicated Scalar Evolution which prints all interesting
transformations done by PSE.
Loop Access Analysis will now print this as part of the analysis output.
We now use this to check the exact expression transformations that were done
by PSE in LAA.
The additional checking also acts as white-box testing for the getAsAddRec method.
Reviewers: anemet, sanjoy
Subscribers: sanjoy, mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D18792
llvm-svn: 266334
Etienne Bergeron [Thu, 14 Apr 2016 16:08:04 +0000 (16:08 +0000)]
[clang-tidy] Fix documentation generation.
Summary: The patch is fixing the generation of clang-tidy documentation.
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19121
llvm-svn: 266333
Jonathan Peyton [Thu, 14 Apr 2016 16:06:49 +0000 (16:06 +0000)]
[ITTNOTIFY] Correct barrier imbalance time in case of tasks
ittnotify fix for barrier imbalance time in case tasks exist. In the current
implementation, task execution time is included into aggregated time on a
barrier. This fix calculates task execution time and corrects the arrive time
by subtracting the task execution time.
Since __kmp_invoke_task() can not only be called on a barrier, the field
th.th_bar_arrive_time is used to check if the function was called at the
barrier (th.th_bar_arrive_time != 0). So for this check, th_bar_arrive_time
is set to zero right after the value is used on the barrier.
Differential Revision: http://reviews.llvm.org/D19030
llvm-svn: 266332
Aaron Ballman [Thu, 14 Apr 2016 16:05:45 +0000 (16:05 +0000)]
Add typedefNameDecl() and typeAliasDecl() to the AST matchers; improves hasType() to match on TypedefNameDecl nodes.
Patch by Clement Courbet.
llvm-svn: 266331
Rafael Espindola [Thu, 14 Apr 2016 16:05:42 +0000 (16:05 +0000)]
Remove the only case where we would relocate a R_386_TLS_TPOFF.
llvm-svn: 266330
Jonathan Peyton [Thu, 14 Apr 2016 16:00:37 +0000 (16:00 +0000)]
Exponential back off logic for test-and-set lock
This change adds back off logic in the test and set lock for better contended
lock performance. It uses a simple truncated binary exponential back off
function. The default back off parameters are tuned for x86.
The main back off logic has a two loop structure where each is controlled by a
user-level parameter:
max_backoff - limits the outer loop number of iterations.
This parameter should be a power of 2.
min_ticks - the inner spin wait loop number of "ticks" which is system
dependent and should be tuned for your system if you so choose.
The "ticks" on x86 correspond to the time stamp counter,
but on other architectures ticks is a timestamp derived
from gettimeofday().
The user can modify these via the environment variable:
KMP_SPIN_BACKOFF_PARAMS=max_backoff[,min_ticks]
Currently, since the default user lock is a queuing lock,
one would have to also specify KMP_LOCK_KIND=tas to use the test-and-set locks.
Differential Revision: http://reviews.llvm.org/D19020
llvm-svn: 266329
Rafael Espindola [Thu, 14 Apr 2016 15:56:14 +0000 (15:56 +0000)]
Merge duplicated cases. NFC.
llvm-svn: 266328
Pavel Labath [Thu, 14 Apr 2016 15:52:58 +0000 (15:52 +0000)]
[test] make expect_state_changes actually expect *only* them
The android dirty stderr problem has uncovered an issue where lldbutil.expect_state_changes was
reading events other than state change events, which resulted in general confusion. Make it more
strict to accept *only* state changes.
llvm-svn: 266327
Pavel Labath [Thu, 14 Apr 2016 15:52:53 +0000 (15:52 +0000)]
[test] Relax stderr expectations on targets with chatty output
Summary:
On some android targets, a binary can produce additional garbage (e.g. warning messages from the
dynamic linker) on the standard error, which confuses some tests. This relaxes the stderr
expectations for targets known for their chattyness.
Reviewers: tfiala, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D19114
llvm-svn: 266326
Ismail Donmez [Thu, 14 Apr 2016 15:32:24 +0000 (15:32 +0000)]
Fix testcase for the LLVM_LIBDIR_SUFFIX=64 case. Fallout from r266108.
llvm-svn: 266324
Michael Kruse [Thu, 14 Apr 2016 15:22:13 +0000 (15:22 +0000)]
Add contexts to test cases. NFC.
As discussed in the Polly weekly phone call and reviews.llvm.org/D18878,
the assumed contexts changed (widen) due to D18878/r265942. Also check
these contexts in the tests affected by that change.
llvm-svn: 266323
Michael Kruse [Thu, 14 Apr 2016 15:22:04 +0000 (15:22 +0000)]
Add InvalidContext to update_test.py.
This allows the test update script to add 'Invalid Context:' to test
cases. Enable with --check-include=InvalidContext.
llvm-svn: 266322
Marianne Mailhot-Sarrasin [Thu, 14 Apr 2016 14:56:49 +0000 (14:56 +0000)]
clang-format: Last line in incomplete block is indented incorrectly
Indentation of the last line was reset to the initial indentation of the block when reaching EOF.
Patch by Maxime Beaulieu
Differential Revision: http://reviews.llvm.org/D19065
llvm-svn: 266321
Marianne Mailhot-Sarrasin [Thu, 14 Apr 2016 14:52:26 +0000 (14:52 +0000)]
clang-format: Implemented tab usage for continuation and indentation
Use tabs to fill whitespace at the start of a line.
Patch by Maxime Beaulieu
Differential Revision: http://reviews.llvm.org/D19028
llvm-svn: 266320
Marianne Mailhot-Sarrasin [Thu, 14 Apr 2016 14:47:37 +0000 (14:47 +0000)]
clang-format: Allow include of clangFormat.h in managed context
Including VirtualFileSystem.h in the clangFormat.h indirectly includes <atomic>.
This header is blocked when compiling with /clr.
Patch by Maxime Beaulieu
Differential Revision: http://reviews.llvm.org/D19064
llvm-svn: 266319
Rafael Espindola [Thu, 14 Apr 2016 14:40:38 +0000 (14:40 +0000)]
Add missing typename.
llvm-svn: 266318
George Rimar [Thu, 14 Apr 2016 14:37:59 +0000 (14:37 +0000)]
[ELF] - Refactoring of end/edata/etext implementation.
Minor refactoring of how end/edata/etext symbols are handled.
Differential revision: http://reviews.llvm.org/D19109
llvm-svn: 266317
Ulrich Weigand [Thu, 14 Apr 2016 14:36:29 +0000 (14:36 +0000)]
Find .plt section in object files generated by recent ld
Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info
field of the .rel(a).plt section identifies the .plt section.
However, with recent GNU ld this is no longer true. As a result of this:
https://sourceware.org/bugzilla/show_bug.cgi?id=18169
in object files generated with current linkers the sh_info field of
.rel(a).plt now points to the .got.plt section (or .got on some targets).
This causes LLDB to fail to identify any PLT stubs, causing a number of
test case failures.
This patch changes LLDB to simply always look for the .plt section by
name. This should be safe across all linkers and targets.
Differential Revision: http://reviews.llvm.org/D18973
llvm-svn: 266316
Ulrich Weigand [Thu, 14 Apr 2016 14:35:02 +0000 (14:35 +0000)]
Fix test cases for big-endian systems
A number of test cases were failing on big-endian systems simply due to
byte order assumptions in the tests themselves, and no underlying bug
in LLDB.
These two test cases:
tools/lldb-server/lldbgdbserverutils.py
python_api/process/TestProcessAPI.py
actually check for big-endian target byte order, but contain Python errors
in the corresponding code paths.
These test cases:
functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
python_api/sbdata/TestSBData.py (first change)
could be fixed to check for big-endian target byte order and update the
expected result strings accordingly. For the two synthetic tests, I've
also updated the source to make sure the fake_a value is always nonzero
on both big- and little-endian platforms.
These test case:
python_api/sbdata/TestSBData.py (second change)
functionalities/memory/cache/TestMemoryCache.py
simply accessed memory with the wrong size, which wasn't noticed on LE
but fails on BE.
Differential Revision: http://reviews.llvm.org/D18985
llvm-svn: 266315
Ulrich Weigand [Thu, 14 Apr 2016 14:34:19 +0000 (14:34 +0000)]
Fix ARM instruction emulation tests on big-endian systems
Running the ARM instruction emulation test on a big-endian system
would fail, since the code doesn't respect endianness properly.
In EmulateInstructionARM::TestEmulation, code assumes that an
instruction opcode read in from the test file is in target byte
order, but it was in fact read in in host byte order.
More difficult to fix, the EmulationStateARM structure models
the overlapping sregs and dregs by a union in _sd_regs. This
only works correctly if the host is a little-endian system.
I've removed the union in favor of a simple array containing
the 32 sregs, and changed any code accessing dregs to explicitly
use the correct two sregs overlaying that dreg in the proper
target order.
Also, the EmulationStateARM::ReadPseudoMemory and WritePseudoMemory
track memory as a map of uint32_t values in host byte order, and
implement 64-bit memory accessing by splitting them up into two
uint32_t ones. However, callers expect memory contents to be
provided in the form of a byte array (in target byte order).
This means the uint32_t contents need to be byte-swapped on
BE systems, and when splitting up a 64-bit access into two 32-bit
ones, byte order has to be respected.
Differential Revision: http://reviews.llvm.org/D18984
llvm-svn: 266314
Ulrich Weigand [Thu, 14 Apr 2016 14:33:47 +0000 (14:33 +0000)]
Miscellaneous fixes for big-endian systems
This patch fixes a bunch of issues that show up on big-endian systems:
- The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes
bit vectors: it should identify the enclosing *word* and then access
the appropriate bit within that word. Instead, the script simply
operates on bytes. This gives the same result on little-endian
systems, but not on big-endian.
- lldb_private::formatters::WCharSummaryProvider always assumes wchar_t
is UTF16, even though it could also be UTF8 or UTF32. This is mostly
not an issue on little-endian systems, but immediately fails on BE.
Fixed by checking the size of wchar_t like WCharStringSummaryProvider
already does.
- ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access
the virtual base offset stored in the vtable, even though the size
of this field matches the target pointer size according to the C++
ABI. Again, this is mostly not visible on LE, but fails on BE.
- Process::ReadStringFromMemory uses strncmp to search for a terminator
consisting of multiple zero bytes. This doesn't work since strncmp
will stop already at the first zero byte. Use memcmp instead.
Differential Revision: http://reviews.llvm.org/D18983
llvm-svn: 266313
Ulrich Weigand [Thu, 14 Apr 2016 14:32:57 +0000 (14:32 +0000)]
Handle bit fields on big-endian systems correctly
Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.
On many big-endian systems, however, the big-endian bit numbering
is used for bit fields. Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.
Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use. However, there are two problems with
the current approach:
- When parsing DWARF, LLDB decodes bit offsets in little-endian
bit numbering on LE systems, but in big-endian bit numbering
on BE systems. Passing those offsets later on into the
DataExtractor routines gives incorrect results on BE.
- In the interim, LLDB's type layer combines byte and bit offsets
into a single number. I.e. instead of recording bitfields by
specifying the byte offset and byte size of the surrounding
integer *plus* the bit offset of the bit field within that field,
it simply records a single bit offset number.
Now, note that converting from byte offset + bit offset to a
single offset value and back is well-defined if we either use
little-endian byte order *and* little-endian bit numbering,
or use big-endian byte order *and* big-endian bit numbering.
Any other combination will yield incorrect results.
Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order. This makes
storing a single bit offset valid, and makes the existing DWARF
code correct. The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.
However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields. While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering. Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.
Differential Revision: http://reviews.llvm.org/D18982
llvm-svn: 266312
Ulrich Weigand [Thu, 14 Apr 2016 14:32:01 +0000 (14:32 +0000)]
Fix usage of APInt.getRawData for big-endian systems
The Scalar implementation and a few other places in LLDB directly
access the internal implementation of APInt values using the
getRawData method. Unfortunately, pretty much all of these places
do not handle big-endian systems correctly. While on little-endian
machines, the pointer returned by getRawData can simply be used as
a pointer to the integer value in its natural format, no matter
what size, this is not true on big-endian systems: getRawData
actually points to an array of type uint64_t, with the first element
of the array always containing the least-significant word of the
integer. This means that if the bitsize of that integer is smaller
than 64, we need to add an offset to the pointer returned by
getRawData in order to access the value in its natural type, and
if the bitsize is *larger* than 64, we actually have to swap the
constituent words before we can access the value in its natural type.
This patch fixes every incorrect use of getRawData in the code base.
For the most part, this is done by simply removing uses of getRawData
in the first place, and using other APInt member functions to operate
on the integer data.
This can be done in many member functions of Scalar itself, as well
as in Symbol/Type.h and in IRInterpreter::Interpret. For the latter,
I've had to add a Scalar::MakeUnsigned routine to parallel the existing
Scalar::MakeSigned, e.g. in order to implement an unsigned divide.
The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong
were already unused and can be simply removed. I've also removed
the Scalar::GetRawBits64 function and its few users.
The one remaining user of getRawData in Scalar.cpp is GetBytes.
I've implemented all the cases described above to correctly
implement access to the underlying integer data on big-endian
systems. GetData now simply calls GetBytes instead of reimplementing
its contents.
Finally, two places in the clang interface code were also accessing
APInt.getRawData in order to actually construct a byte representation
of an integer. I've changed those to make use of a Scalar instead,
to avoid having to re-implement the logic there.
The patch also adds a couple of unit tests verifying correct operation
of the GetBytes routine as well as the conversion routines. Those tests
actually exposed more problems in the Scalar code: the SetValueFromData
routine didn't work correctly for 128- and 256-bit data types, and the
SChar routine should have an explicit "signed char" return type to work
correctly on platforms where char defaults to unsigned.
Differential Revision: http://reviews.llvm.org/D18981
llvm-svn: 266311
Ulrich Weigand [Thu, 14 Apr 2016 14:31:08 +0000 (14:31 +0000)]
Make Scalar::GetBytes and RegisterValue::GetBytes const
Scalar::GetBytes provides a non-const access to the underlying bytes
of the scalar value, supposedly allowing for modification of those
bytes. However, even with the current implementation, this is not
really possible. For floating-point scalars, the pointer returned
by GetBytes refers to a temporary copy; modifications to that copy
will be simply ignored. For integer scalars, the pointer refers
to internal memory of the APInt implementation, which isn't
supposed to be directly modifyable; GetBytes simply casts aways
the const-ness of the pointer ...
With my upcoming patch to fix Scalar::GetBytes for big-endian
systems, this problem is going to get worse, since there we need
temporary copies even for some integer scalars. Therefore, this
patch makes Scalar::GetBytes const, fixing all those problems.
As a follow-on change, RegisterValues::GetBytes must be made const
as well. This in turn means that the way of initializing a
RegisterValue by doing a SetType followed by writing to GetBytes
no longer works. Instead, I've changed SetValueFromData to do
the equivalent of SetType itself, and then re-implemented
SetFromMemoryData to work on top of SetValueFromData.
There is still a need for RegisterValue::SetType, since some
platform-specific code uses it to reinterpret the contents of
an already filled RegisterValue. To make this usage work in
all cases (even changing from a type implemented via Scalar
to a type implemented as a byte buffer), SetType now simply
copies the old contents out, and then reloads the RegisterValue
from this data using the new type via SetValueFromData.
This in turn means that there is no remaining caller of
Scalar::SetType, so it can be removed.
The only other follow-on change was in MIPS EmulateInstruction
code, where some uses of RegisterValue::GetBytes could be made
const trivially.
Differential Revision: http://reviews.llvm.org/D18980
llvm-svn: 266310
Ulrich Weigand [Thu, 14 Apr 2016 14:30:12 +0000 (14:30 +0000)]
Fixes for platforms that default to unsigned char
This fixes several test case failure on s390x caused by the fact that
on this platform, the default "char" type is unsigned.
- In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return
an explicit *signed* char type for encoding eEncodingSint and bit size 8,
instead of the default platform char type (which may be unsigned).
This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize,
and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize
unit test case.
- The test/expression_command/char/TestExprsChar.py test case is known to
fail on platforms defaulting to unsigned char (pr23069), and just needs
to be xfailed on s390x like on arm.
- The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test
case defines a vector of "char" and implicitly assumes to be signed.
Use an explicit "signed char" instead.
Differential Revision: http://reviews.llvm.org/D18979
llvm-svn: 266309
Ulrich Weigand [Thu, 14 Apr 2016 14:28:34 +0000 (14:28 +0000)]
Support Linux on SystemZ as platform
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform
This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).
There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).
The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:
- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.
- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]
Differential Revision: http://reviews.llvm.org/D18978
llvm-svn: 266308
Ulrich Weigand [Thu, 14 Apr 2016 14:25:20 +0000 (14:25 +0000)]
Add new ABI callback to provide fallback unwind register locations
If the UnwindPlan did not identify how to unwind the stack pointer
register, LLDB currently assumes it can determine to caller's SP
from the current frame's CFA. This is true on most platforms
where CFA is by definition equal to the incoming SP at function
entry.
However, on the s390x target, we instead define the CFA to equal
the incoming SP plus an offset of 160 bytes. This is because
our ABI defines that the caller has to provide a register save
area of size 160 bytes. This area is allocated by the caller,
but is considered part of the callee's stack frame, and therefore
the CFA is defined as pointing to the top of this area.
In order to make this work on s390x, this patch introduces a new
ABI callback GetFallbackRegisterLocation that provides platform-
specific fallback register locations for unwinding. The existing
code to handle SP unwinding as well as volatile registers is moved
into the default implementation of that ABI callback, to allow
targets where that implementation is incorrect to override it.
This patch in itself is a no-op for all existing platforms.
But it is a pre-requisite for adding s390x support.
Differential Revision: http://reviews.llvm.org/D18977
llvm-svn: 266307
George Rimar [Thu, 14 Apr 2016 14:24:23 +0000 (14:24 +0000)]
Return back the zero parameter of aggregate initialization in OutputSectionFactory::lookup().
That was removed in r266304, but leads to warnings by Clang.
Thanks to Rafael EspĂndola for pointing on that.
Though I think change was legal from point of C++.
llvm-svn: 266306
Ed Maste [Thu, 14 Apr 2016 14:17:42 +0000 (14:17 +0000)]
[sanitizer] remove FreeBSD PS_STRINGS fallback
The PS_STRINGS constant can easily be incorrect with mismatched
kernel/userland - e.g. when building i386 sanitizers on FreeBSD/amd64
with -m32. The kern.ps_strings sysctl was introduced over 20 years ago
as the supported way to fetch the environment and argument string
addresses from the kernel, so the fallback is never used.
Differential Revision: http://reviews.llvm.org/D19027
llvm-svn: 266305
George Rimar [Thu, 14 Apr 2016 14:07:54 +0000 (14:07 +0000)]
Make OutputSectionFactory::lookup() inline. NFC.
Also I removed the last zero parameter of
aggregate initialization as it is excessive here.
llvm-svn: 266304
George Rimar [Thu, 14 Apr 2016 13:56:28 +0000 (13:56 +0000)]
Removed excessive line. NFC.
llvm-svn: 266303
George Rimar [Thu, 14 Apr 2016 13:47:04 +0000 (13:47 +0000)]
Reduce expression to single line. NFC.
llvm-svn: 266302
Simon Dardis [Thu, 14 Apr 2016 13:43:17 +0000 (13:43 +0000)]
Summary:
Alias 'jic $reg, 0' to 'jrc $reg' and 'jialc $reg, 0' to 'jalrc $reg' like
binutils.
This patch was previous committed as r266055 as seemed to have caused some spurious
test failures. They did not reappear after further local testing.
llvm-svn: 266301
Renato Golin [Thu, 14 Apr 2016 13:31:22 +0000 (13:31 +0000)]
Revert "Make tsan tests more portable (take 2)"
This reverts commit r266294, as it broke some buildbots again. :/
llvm-svn: 266300
George Rimar [Thu, 14 Apr 2016 13:23:02 +0000 (13:23 +0000)]
Clang formated file. NFC.
llvm-svn: 266299
George Rimar [Thu, 14 Apr 2016 13:00:03 +0000 (13:00 +0000)]
Combine code branch into single line. NFC.
llvm-svn: 266298
Marcin Koscielnicki [Thu, 14 Apr 2016 12:56:24 +0000 (12:56 +0000)]
[sanitizer] [SystemZ] Abort if the kernel might be vulnerable to CVE-2016-2143.
In short, CVE-2016-2143 will crash the machine if a process uses both >4TB
virtual addresses and fork(). ASan, TSan, and MSan will, by necessity, map
a sizable chunk of virtual address space, which is much larger than 4TB.
Even worse, sanitizers will always use fork() for llvm-symbolizer when a bug
is detected. Disable all three by aborting on process initialization if
the running kernel version is not known to contain a fix.
Unfortunately, there's no reliable way to detect the fix without crashing
the kernel. So, we rely on whitelisting - I've included a list of upstream
kernel versions that will work. In case someone uses a distribution kernel
or applied the fix themselves, an override switch is also included.
Differential Revision: http://reviews.llvm.org/D18915
llvm-svn: 266297
Marcin Koscielnicki [Thu, 14 Apr 2016 12:56:15 +0000 (12:56 +0000)]
[sanitizer] [SystemZ] Add virtual space size.
This teaches sanitizer_common about s390 and s390x virtual space size.
s390 is unusual in that it has 31-bit virtual space.
Differential Revision: http://reviews.llvm.org/D18896
llvm-svn: 266296
Marcin Koscielnicki [Thu, 14 Apr 2016 12:51:45 +0000 (12:51 +0000)]
[sanitizer] [SystemZ] Implement internal_mmap.
mmap on s390 is quite a special snowflake: since it has too many
parameters to pass them in registers, it passes a pointer to a struct
with all the parameters instead.
Differential Revision: http://reviews.llvm.org/D18889
llvm-svn: 266295
Renato Golin [Thu, 14 Apr 2016 12:10:21 +0000 (12:10 +0000)]
Make tsan tests more portable (take 2)
Using stderr more uniformily, avoiding potential races when scanning stdout
and stderr output.
Patch by Maxim Kuvyrkov.
llvm-svn: 266294
Gabor Horvath [Thu, 14 Apr 2016 11:56:28 +0000 (11:56 +0000)]
[analyzer] Make it possible to query the function name from a CallDescription.
llvm-svn: 266293
Artem Dergachev [Thu, 14 Apr 2016 11:51:27 +0000 (11:51 +0000)]
[ASTImporter] Implement some expression-related AST node import.
Introduce ASTImporter unit test framework.
Fix a memory leak introduced in
cf8ccff5: an array is allocated
in ImportArray and never freed.
Support new node kinds:
- GCCAsmStmt
- AddrLabelExpr
- AtomicExpr
- CompoundLiteralExpr
- CXXBoolLiteralExpr
- CXXNullPtrLiteralExpr
- CXXThisExpr
- DesignatedInitExpr
- GNUNullExpr
- ImplicitValueInitExpr
- InitListExpr
- OpaqueValueExpr
- PredefinedExpr
- ParenListExpr
- StmtExpr
- VAArgExpr
- BinaryConditionalOperator
- ConditionalOperator
- FloatingLiteral
- StringLiteral
- InjectedClassNameType
- TemplateTypeParmType
- LabelDecl
Patch by Aleksei Sidorin!
Differential Revision: http://reviews.llvm.org/D14286
llvm-svn: 266292
Dmitry Vyukov [Thu, 14 Apr 2016 11:40:08 +0000 (11:40 +0000)]
asan: fix build
Some bots failed with:
sanitizer_quarantine.h:104:7: error: unused typedef 'assertion_failed__104' [-Werror,-Wunused-local-typedef]
COMPILER_CHECK(kPrefetch <= ARRAY_SIZE(b->batch));
Replace COMPILER_CHECK with CHECK.
llvm-svn: 266291
Nico Weber [Thu, 14 Apr 2016 11:12:32 +0000 (11:12 +0000)]
Reapply r258505 after r266254, this time with a comment to make it more sticky.
llvm-svn: 266290
Igor Kudrin [Thu, 14 Apr 2016 10:43:37 +0000 (10:43 +0000)]
[Coverage] Update testing methods to support more than two files
Differential Revision: http://reviews.llvm.org/D18757
llvm-svn: 266289
Dmitry Vyukov [Thu, 14 Apr 2016 09:52:33 +0000 (09:52 +0000)]
asan: fix out-of-bounds access in quarantine
llvm-svn: 266288
Dmitry Polukhin [Thu, 14 Apr 2016 09:52:06 +0000 (09:52 +0000)]
[MSVC] Fix check for wchar_t type in case of -fno-wchar
The example below should work identically with and without compiler native
wchar_t support.
void foo(wchar_t * t = L"");
Differential Revision: http://reviews.llvm.org/D19056
llvm-svn: 266287
Pavel Labath [Thu, 14 Apr 2016 09:38:06 +0000 (09:38 +0000)]
FileSpec: make matching separator-agnostic again
Summary:
In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed
needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with
backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a
problem because we would consider paths with different separators as different (which led to
unresolved breakpoints for instance).
Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I
am commenting out the GetDirectory unittests until we figure out the what is the expected
behaviour here.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19060
llvm-svn: 266286
Vasileios Kalintiris [Thu, 14 Apr 2016 09:13:13 +0000 (09:13 +0000)]
[mips] Remove duplicate tests and add missing prefixes for *-LABEL checks. NFC.
Summary:
The only difference between the removed tests and the pre-existing
ones, is the materialization of the zero constant, which shouldn't
matter for these cases.
Reviewers: dsanders, sdardis
Subscribers: dsanders, sdardis, llvm-commits
Differential Revision: http://reviews.llvm.org/D18693
llvm-svn: 266285
Igor Kudrin [Thu, 14 Apr 2016 09:10:00 +0000 (09:10 +0000)]
[Coverage] Avoid unnecessary copying of std::vector
Approved by: Justin Bogner <mail@justinbogner.com>
Differential Revision: http://reviews.llvm.org/D18756
llvm-svn: 266284
Kuba Brecka [Thu, 14 Apr 2016 09:05:19 +0000 (09:05 +0000)]
[tsan] Fix size reporting for OS X zone allocator with 0-sized allocations
The custom zone implementation for OS X must not return 0 (even for 0-sized allocations). Returning 0 indicates that the pointer doesn't belong to the zone. This can break existing applications. The underlaying allocator allocates 1 byte for 0-sized allocations anyway, so returning 1 in this case is okay.
Differential Revision: http://reviews.llvm.org/D19100
llvm-svn: 266283
Adam Nemet [Thu, 14 Apr 2016 08:47:17 +0000 (08:47 +0000)]
Revert "Support arbitrary addrspace pointers in masked load/store intrinsics"
This reverts commit r266086.
It breaks the LTO build of gcc in SPEC2000.
llvm-svn: 266282
Mehdi Amini [Thu, 14 Apr 2016 08:46:22 +0000 (08:46 +0000)]
ThinLTO: linkonce compile-time optimization, do not bother when there is only one input file
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266281
Michael Zuckerman [Thu, 14 Apr 2016 07:56:51 +0000 (07:56 +0000)]
[Clang][AVX512][BUILTIN] Adding support for intrinsics of vpmov{d|q}{b|w|d}{128|256|512} instruction set
Differential Revision: http://reviews.llvm.org/D19055
llvm-svn: 266280
David Majnemer [Thu, 14 Apr 2016 07:13:24 +0000 (07:13 +0000)]
[CodeGen] Teach LLVM how to lower @llvm.{min,max}num to {MIN,MAX}NAN
The behavior of {MIN,MAX}NAN differs from that of {MIN,MAX}NUM when only
one of the inputs is NaN: -NUM will return the non-NaN argument while
-NAN would return NaN.
It is desirable to lower to @llvm.{min,max}num to -NAN if they don't
have a native instruction for -NUM. Notably, ARMv7 NEON's vmin has the
-NAN semantics.
N.B. Of course, it is only safe to do this if the intrinsic call is
marked nnan.
llvm-svn: 266279
Michael Zuckerman [Thu, 14 Apr 2016 06:48:09 +0000 (06:48 +0000)]
[Clang][AVX512][Builtin] Adding intrinsics of vpmovus{d|q}{b|w|d}{128|256|512} instruction set
Differential Revision: http://reviews.llvm.org/D19050
llvm-svn: 266278
Mehdi Amini [Thu, 14 Apr 2016 05:37:41 +0000 (05:37 +0000)]
Make sure the LLVMContext outlive the CompilerInstance
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266277
Mehdi Amini [Thu, 14 Apr 2016 05:34:32 +0000 (05:34 +0000)]
Do not use llvm:getGlobalContext() in unittests
Currently trying to nuke this API from LLVM.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266276
Mehdi Amini [Thu, 14 Apr 2016 04:36:40 +0000 (04:36 +0000)]
Do not use getGlobalContext()... ever.
This code was creating a new type in the global context, regardless
of which context the user is sitting in, what can possibly go wrong?
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266275
Oleksiy Vyalov [Thu, 14 Apr 2016 02:02:12 +0000 (02:02 +0000)]
Fix Android build after r266267
llvm-svn: 266274
Peter Collingbourne [Thu, 14 Apr 2016 01:48:11 +0000 (01:48 +0000)]
ELF: Do not create copy relocations for references in writable sections.
They are unnecessary, as the dynamic loader can apply the original relocations
directly. This was also resulting in the creation of copy relocations in PIEs.
Differential Revision: http://reviews.llvm.org/D19089
llvm-svn: 266273
Matt Arsenault [Thu, 14 Apr 2016 01:42:16 +0000 (01:42 +0000)]
AMDGPU: Implement canonicalize
Also add generic DAG node for it.
llvm-svn: 266272
Enrico Granata [Thu, 14 Apr 2016 01:23:01 +0000 (01:23 +0000)]
Don't use auto - (try to) appease the Android g++ bot
llvm-svn: 266271
Matthias Braun [Thu, 14 Apr 2016 01:10:42 +0000 (01:10 +0000)]
TargetLowering: Factor out common code for tail call eligibility checking; NFC
llvm-svn: 266270
Richard Smith [Thu, 14 Apr 2016 00:50:18 +0000 (00:50 +0000)]
[modules] Store the location of the lexical update record in a decl update as
an offset from the current record rather than as an absolute bit number. This
gives a minor .pcm file size reduction.
llvm-svn: 266269
Alexander Kornienko [Thu, 14 Apr 2016 00:47:40 +0000 (00:47 +0000)]
Reorder ASTNodeKind::AllKindInfo to match NodeKindId.
Summary:
AllKindInfo is being indexed by NodeKindId, so the order must match.
Extended ASTTypeTraits tests to cover this.
Reviewers: sbenza
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D19059
llvm-svn: 266268
Enrico Granata [Thu, 14 Apr 2016 00:43:20 +0000 (00:43 +0000)]
Augment the 'language objc class-table dump' command to take a "-v" option, which makes it print ivar and method information, as well as an optional regex argument which filters out all class names that don't match the regex
llvm-svn: 266267
Richard Smith [Thu, 14 Apr 2016 00:29:55 +0000 (00:29 +0000)]
[modules] Remove CXX_BASE_SPECIFIERS_OFFSETS table. Instead of storing an ID of
a table entry in the corresponding decl, store an offset from the current
record to the relevant CXX_BASE_SPECIFIERS record. This results in fewer
indirections and a minor .pcm file size reduction.
llvm-svn: 266266