This is outdated, there's a bunch of architectures missing. If we want
them to be part of this table they should be a separate row anyway.

llvm-svn: 360967

Previously "bt all    " would've failed as the regex didn't match
them.

Over the shoulder review by Jonas Devlieghere.

<rdar://problem/50824935>

llvm-svn: 360966

Make sure to not unroll a vector division/remainder (with a constant splat
divisor) after type legalization, since the scalar type may then be illegal.

Review: Ulrich Weigand
https://reviews.llvm.org/D62036

llvm-svn: 360965

Unify the padding across list items and the list header.

llvm-svn: 360964

It caused PR41917.

llvm-svn: 360963

Summary:
Rather than duplicating code between PointerUnion, PointerUnion3, and
PointerUnion4 (and missing things from the latter cases, such as some of the
DenseMap support and operator==), convert PointerUnion to a variadic template
that can be used as a union of any number of pointers.

(This doesn't support PointerUnion<> right now. Adding a special case for that
would be possible, and perhaps even useful in some situations, but it doesn't
seem worthwhile until we have a concrete use case.)

Reviewers: dblaikie

Subscribers: dexonsmith, kristina, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D62027

llvm-svn: 360962

These are all of the ones involving the same data layout string.  Remainder take a bit more consideration, but at least everything can be auto-updated now.

llvm-svn: 360961

These are valid Jcc, but aren't based on the EFLAGS condition codes (Intel 64
and IA-32 Architetcures Software Developer's Manual Vol. 1, Appendix B). These
are covered in clang/test, but not llvm/test.

llvm-svn: 360960

Summary:
Adds a call to __hwasan_handle_vfork(SP) at each landingpad entry.

Reusing __hwasan_handle_vfork instead of introducing a new runtime call
in order to be ABI-compatible with old runtime library.

Reviewers: pcc

Subscribers: kubamracek, hiraditya, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D61968

llvm-svn: 360959

llvm-svn: 360958

Newly written tests to cover the simple cases.  We don't appear to have broad coverage of this transform anywhere.

llvm-svn: 360957

llvm-svn: 360956

The change broke some scenarios where debug information is still
needed, although MarkLive cannot see it, including the
Chromium/Android build. Reverting to unbreak that build.

llvm-svn: 360955

In Intel syntax, it's not uncommon to see a "short" modifier on Jcc conditional
jumps, which indicates the offset should be a "short jump" (8-bit immediate
offset from EIP, -128 to +127). This patch expands to all recognized Jcc
condition codes, and removes the inline restriction.

Clang already ignores "jmp short" in inline assembly. However, only "jmp" and a
couple of Jcc are actually checked, and only inline (i.e., not when using the
integrated assembler for asm sources). A quick search through asm-containing
libraries at hand shows a pretty broad range of Jcc conditions spelled with
"short."

GAS ignores the "short" modifier, and instead uses an encoding based on the
given immediate. MS inline seems to do the same, and I suspect MASM does, too.
NASM will yield an error if presented with an out-of-range immediate value.

Example of GCC 9.1 and MSVC v19.20, "jmp short" with offsets that do and do not
fit within 8 bits: https://gcc.godbolt.org/z/aFZmjY

Differential Revision: https://reviews.llvm.org/D61990

llvm-svn: 360954

This better matches the verbiage in Intel documentation, and should help avoid
confusion between these two different kinds of values, both of which are parsed
from mnemonics.

llvm-svn: 360953

Summary:
This refactors four pieces of code that create SDNodes for references to
symbols:
- normal global address lowering (LEA, MOV, etc)
- callee global address lowering (CALL)
- external symbol address lowering (LEA, MOV, etc)
- external symbol address lowering (CALL)

Each of these pieces of code need to:
- classify the reference
- lower the symbol
- emit a RIP wrapper if needed
- emit a load if needed
- add offsets if needed

I think handling them all in one place will make the code easier to
maintain in the future.

Reviewers: craig.topper, RKSimon

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D61690

llvm-svn: 360952

llvm-svn: 360951

Summary:
This emits S_CONSTANT records for global variables.
Currently this emits records for the global variables already being tracked in the
LLVM IR metadata, which are just constant global variables; we'll also want S_CONSTANTs
for static data members and enums.

Related to https://bugs.llvm.org/show_bug.cgi?id=41615

Reviewers: rnk

Subscribers: aprantl, hiraditya, llvm-commits, thakis

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D61926

llvm-svn: 360948

llvm-svn: 360947

Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.

This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.

Reviewers: tstellar, winksaville

Subscribers: mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61909

llvm-svn: 360946

llvm-svn: 360945

llvm-svn: 360944

llvm-svn: 360943

The recent introduction of v3i32 etc as an MVT, and its use in AMDGPU
3-dword memory instructions, caused a de-optimization problem for code
with such a load that then bitcasts via vector of i8, because v12i8 is
not an MVT so it legalizes the bitcast by widening it.

This commit adds the ability to widen a bitcast using extract_subvector
on the result, so the value does not need to go via memory.

Differential Revision: https://reviews.llvm.org/D60457

Change-Id: Ie4abb7760547e54a2445961992eafc78e80d4b64
llvm-svn: 360942

Previously these sections were being generated during their
constructors.  This moves the work to finalizeContent, and also does
the same for the relocation sections because their contents depends
on the final layout too.

This change is part of a larger refactor to how we deal with synthetic
sections: https://reviews.llvm.org/D61811

Differential Revision: https://reviews.llvm.org/D61971

llvm-svn: 360941

Differential Revision: https://reviews.llvm.org/D61991

llvm-svn: 360940

This tool is needed by clang/test/CodeGen/Output/ppc-mmintrin.c.

llvm-svn: 360939

This relands commit rL360833 which caused issues on Win32
bots due to path handling/normalization differences. Now
this uses `sys::path::filename` which should handle
additional edge cases on Win32.

Original commit:

"[Clang][PP] Add the __FILE_NAME__ builtin macro" 

This patch adds the __FILE_NAME__ macro that expands to the
last component of the path, similar to __FILE__ except with
a guarantee that only the last path component (without the
separator) will be rendered.

I intend to follow through with discussion of this with WG14
as a potential inclusion in the C standard or failing that,
try to discuss this with GCC developers since this extension
is desired by GCC and Clang users/developers alike.

Differential Revision: https://reviews.llvm.org/D61756

llvm-svn: 360938

Summary:
This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation).

With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. 

Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong

Reviewed By: rsmith

Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits

Differential Revision: https://reviews.llvm.org/D37035

llvm-svn: 360937

llvm-svn: 360936

This test hadn't been fully reduced, so do so.

llvm-svn: 360935

llvm-svn: 360934

llvm-svn: 360933

llvm-svn: 360932

llvm-svn: 360931

This addresses post-commit review feedback for https://reviews.llvm.org/D62015.

llvm-svn: 360930

This fixes an unintended regression introduced by
https://reviews.llvm.org/D61451 by making sure the Objective-C runtime
is also tried when the "correct" language runtime failed to return an
object description.

rdar://problem/50791055

Differential Revision: https://reviews.llvm.org/D62015

llvm-svn: 360929

These were new tests I added in r360808. I made a mistake while converting the exisiting binary FNeg test into the new unary FNeg tests. Correct that.

llvm-svn: 360928

Use FileCheck's --implicit-check-not='ThreadSanitizer' which increases
the strictness of our tests a bit. NFC.

```
CHECK: start
CHECK-NOT: ThreadSanitizer
CHECK: done
```

With --implicit-check-not, the above is turned into:

```
CHECK-NOT: ThreadSanitizer
CHECK: start
CHECK-NOT: ThreadSanitizer
CHECK: done
CHECK-NOT: ThreadSanitizer
```

llvm-svn: 360927

SymbolStringPtr used to use nullptr as its empty value and (since it performed
ref-count operations on any non-nullptr) a pointer to a special pool-entry
instance as its tombstone.

This commit changes the scheme to use two invalid pointer values as the empty
and tombstone values, and broadens the ref-count guard to prevent ref-counting
operations from being performed on these pointers. This should improve the
performance of SymbolStringPtrs used in DenseMaps/DenseSets, as ref counting
operations will no longer be performed on the tombstone.

llvm-svn: 360925