In some cases, a typedef only strips aways a keyword for a type, keeping the
same name as the root record type.  This causes some confusion when the type
is defined in one modules but only forward declared in another.  Skipping the
typedef and going straight to the record will avoid this issue.

typedef struct S {} S;
S* s;  // S is TypedefType here

struct S;
S* s;  // S is RecordType here

llvm-svn: 364119

-d code.

Summary:
Move it into `main` function so the checking is effective for all actions
user may do with llvm-objdump; notably, -r and -s in addition to existing -d.

Match GNU behavior.

Reviewers: jhenderson, grimar, MaskRay, rupprecht

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 364118

To help produce better diagnostics for stack use-after-return, we'd like
to be able to determine the addresses of each HWASANified function's local
variables given a small amount of information recorded on entry to the
function. Currently we require all HWASANified functions to use frame pointers
and record (PC, FP) on function entry. This works better than recording SP
because FP cannot change during the function, unlike SP which can change
e.g. due to dynamic alloca.

However, most variables currently end up using SP-relative locations in their
debug info. This prevents us from recomputing the address of most variables
because the distance between SP and FP isn't recorded in the debug info. To
address this, make the AArch64 backend prefer FP-relative debug locations
when producing debug info for HWASANified functions.

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

llvm-svn: 364117

llvm-svn: 364116

On Windows ARM64, intrinsic __debugbreak is compiled into brk #0xF000 which is
mapped to llvm.debugtrap in Clang. Instruction brk #F000 is the defined break
point instruction on ARM64 which is recognized by Windows debugger and
exception handling code, so llvm.debugtrap should map to it instead of
redirecting to llvm.trap (brk #1) as the default implementation.

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

llvm-svn: 364115

Using class templates instead of alias templates causes a lot of
instantiations. As part of the move away from C++03, we want to
improve the efficiency of our meta-programming.

This patch lays the groundwork by introducing new _If, _EnableIf,
_And, _Or, and _IsValidExpansion (detect member). Future patches
will replace the existing implementations after verifying there
compile time differences.

llvm-svn: 364114

No need to compute the path of lit-lldb-init twice.

llvm-svn: 364113

This makes the `lit-lldb-init` file configurable by CMake. This matters
to us downstream in Swift, where we want to set environment variables
with the `env` command for every test.

Differential revision: https://reviews.llvm.org/D63679

llvm-svn: 364112

This reverts r364084 (git commit 5698921b)

It caused crashes while compiling a file in Chrome. Reduction
forthcoming.

llvm-svn: 364111

llvm-svn: 364110

A handful of C++ cases as reported in PR42352 didn't actually give an
error when always_inlining with a different target feature list. This
resulted in broken IR.

llvm-svn: 364109

llvm-svn: 364108

Creates thin output file of specified arch_type from the fat input file.

Patch by Anusha Basana <anushabasana@fb.com>

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

llvm-svn: 364107

Summary: The fixit `int square(int /*num*/)` yields `error: parameter name omitted` for C code. Enable it only for C++ code.

Reviewers: klimek, ilya-biryukov, lebedev.ri, aaron.ballman

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 364106

The VM layout on iOS is not stable between releases. On 64-bit iOS and
its derivatives we use a dynamic shadow offset that enables ASan to
search for a valid location for the shadow heap on process launch rather
than hardcode it.

This commit extends that approach for 32-bit iOS plus derivatives and
their simulators.

rdar://50645192
rdar://51200372
rdar://51767702

Reviewed By: delcypher

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

llvm-svn: 364105

The indentation of the return here was off, and confusing as a result.
Cleaned up a bit extra while I was in the area.

llvm-svn: 364104

crashing.

Ideally we wouldn't care about the size of a file so long as it fits in
memory, but in practice we have lots of hardocded assumptions that
unsigned can be used to index files, string literals, and so on.

llvm-svn: 364103

necessary) leading whitespace.

Simplify unit test and extend to cover no_unique_address attribute.

llvm-svn: 364102

[X86] Add test cases for incorrect shrinking of volatile vector loads from 128-bits to 32 or 64 bits. NFC

This is caused by isel patterns that look for vzmovl+load and
treat it the same as vzload.

llvm-svn: 364101

Summary:
Take advantage of the final keyword to devirtualize destructor calls.

Fix https://bugs.llvm.org/show_bug.cgi?id=21368

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: davidxl, Prazek, cfe-commits

Tags: #clang

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

llvm-svn: 364100

Fixes missing piece from r363990.

llvm-svn: 364099

Summary:
ObjCLanguageRuntime was being pulled into LanguageRuntime because of
Breakpoint Preconditions. If we move BreakpointPrecondition out of Breakpoint,
we can extend the LanguageRuntime plugin interface so that LanguageRuntimes
can give us a BreakpointPrecondition for exceptions.

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

llvm-svn: 364098

[X86] Add DAG combine to turn (vzmovl (insert_subvector undef, X, 0)) into (insert_subvector allzeros, (vzmovl X), 0)

128/256 bit scalar_to_vectors are canonicalized to (insert_subvector undef, (scalar_to_vector), 0). We have isel patterns that try to match this pattern being used by a vzmovl to use a 128-bit instruction and a subreg_to_reg.

This patch detects the insert_subvector undef portion of this and pulls it through the vzmovl, creating a narrower vzmovl and an insert_subvector allzeroes. We can then match the insertsubvector into a subreg_to_reg operation by itself. Then we can fall back on existing (vzmovl (scalar_to_vector)) patterns.

Note, while the scalar_to_vector case is the motivating case I didn't restrict to just that case. I'm also wondering about shrinking any 256/512 vzmovl to an extract_subvector+vzmovl+insert_subvector(allzeros) but I fear that would have bad implications to shuffle combining.

I also think there is more canonicalization we can do with vzmovl with loads or scalar_to_vector with loads to create vzload.

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

llvm-svn: 364095

Implement P0340R3: Make 'underlying_type' SFINAE-friendly. Reviewed as https://reviews.llvm.org/D63574

llvm-svn: 364094

We don't have any Custom handling during type legalization. Only
operation legalization.

Fixes PR42355

llvm-svn: 364093

Prep for fixing PR42355 and ensuring we have coverage of
ISD::SELECT for v64i8/v32i16 on KNL and SKX configs.

llvm-svn: 364092

[X86] Add a debug print of the node in the default case for unhandled opcodes in ReplaceNodeResults.

This should be unreachable, but bugs can make it reachable. This
adds a debug print so we can see the bad node in the output when
the llvm_unreachable triggers.

llvm-svn: 364091

Subvector shuffling often ends up as insert/extract subvector.

llvm-svn: 364090

This reverts r363985 (git commit d5f16d6c)

This test can't use printf on Windows because the path contains
backslashes which must not be interpreted as escapes by printf.

llvm-svn: 364089

and remove the need to use -MD options in the CDB

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

llvm-svn: 364088

These days Python 3 is typically installed into C:/Program Files, so
cope with that.

Similar to r364077 in compiler-rt.

llvm-svn: 364087

With this we can now fully code generate jump tables, which is important for code size.

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

llvm-svn: 364086

[GlobalISel][IRTranslator] Change switch table translation to generate jump tables and range checks.

This change makes use of the newly refactored SwitchLoweringUtils code from
SelectionDAG to in order to generate jump tables and range checks where appropriate.

Much of this code is ported from SDAG with some modifications. We generate
G_JUMP_TABLE and G_BRJT instructions when JT opportunities are found. This means
that targets which previously relied on the naive one MBB per case stmt
translation will now start falling back until they add support for the new opcodes.

For range checks, we don't generate any previously unused operations. This
just recognizes contiguous ranges of case values and generates a single block per
range. Single case value blocks are just a special case of ranges so we get that
support almost for free.

There are still some optimizations missing that I haven't ported over, and
bit-tests are also unimplemented. This patch series is already complex enough.

Actual arm64 support for selection of jump tables is coming in a later patch.

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

llvm-svn: 364085

This patch introduces a new heuristic for guiding operand reordering. The new "look-ahead" heuristic can look beyond the immediate predecessors. This helps break ties when the immediate predecessors have identical opcodes (see lit test for an example).

Committed on behalf of @vporpo (Vasileios Porpodas)

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

llvm-svn: 364084

llvm-svn: 364083

llvm-svn: 364082

llvm-svn: 364081

If the variably modified type is declared outside of the captured region
and then used in the cast expression along with array subscript
expression, the type is not captured and it leads to the compiler crash.

llvm-svn: 364080

We already use vmovq for v2i64/v2f64 vzmovl. But we were using a
blendpd+xorpd for v4i64/v4f64/v8i64/v8f64 under opt speed. Or
movsd+xorpd under optsize.

I think the blend with 0 or movss/d is only needed for
vXi32 where we don't have an instruction that can move 32
bits from one xmm to another while zeroing upper bits.

movq is no worse than blendpd on any known CPUs.

llvm-svn: 364079

llvm-svn: 364078