This was broken by r224120.

llvm-svn: 225130

llvm-svn: 225129

llvm-svn: 225128

We assumed the output of a match was a Value, this would cause us to
assert because we would fail a cast<>.  Instead, use a helper in the
Operator family to hide the distinction between Value and Constant.

This fixes PR22087.

llvm-svn: 225127

PHI nodes can have zero operands in the middle of a transform.  It is
expected that utilities in Analysis don't freak out when this happens.

Note that it is considered invalid to allow these misshapen phi nodes to
make it to another pass.

This fixes PR22086.

llvm-svn: 225126

Also add a few asserts for this.  The existing code assumes this in a bunch
of places already (see e.g. the assert at the top of ParseTypedefDecl(), and
there are many unchecked calls on the result of GetTypeForDeclarator()), and
from looking through the code this should always be true from what I can tell.
This allows removing ASTContext::getNullTypeSourceInfo() too as that's now
unused.

No behavior change intended.

llvm-svn: 225125

Many places in Sema cannot handle isNull() types.  This is fine, because in
most places the type building code recovers by falling back to IntTy.  In
GetFullTypeForDeclarator(), this is done at the end of the getNumTypeObjects()
loop body.  This function calls BuildQualifiedType() before this fallback is
done though, so it explicitly needs to check for isNull() types.

llvm-svn: 225124

This patch adds a check for underflow when truncating results back to lower
precision at the end of an FMA. The additional sign handling logic in
APFloat::fusedMultiplyAdd should only be performed when the result of the
addition step of the FMA (in full precision) is exactly zero, not when the
result underflows to zero.

Unit tests for this case and related signed zero FMA results are included.

Fixes <rdar://problem/18925551>.

llvm-svn: 225123

llvm-svn: 225122

It's reasonable to ask if an l-value with class type is modifiable.

llvm-svn: 225121

This enhances llvm-readobj to print out the COFF export table, similar to the
-coff-import option.  This is useful for testing in lld.

llvm-svn: 225120

Weak externals are resolved statically, so we can actually generate the tail
call on PE/COFF targets without breaking the requirements.  It is questionable
whether we want to propagate the current behaviour for MachO as the requirements
are part of the ARM ELF specifications, and it seems that prior to the SVN
r215890, we would have tail'ed the call.  For now, be conservative and only
permit it on PE/COFF where the call will always be fully resolved.

llvm-svn: 225119

Weird constructs like __attribute__((inline)) or
__attibute__((typename)) should result in warnings, not errors.

llvm-svn: 225118

The existing code provided for specifying a global loop alignment preference.
However, the preferred loop alignment might depend on the loop itself. For
recent POWER cores, loops between 5 and 8 instructions should have 32-byte
alignment (while the others are better with 16-byte alignment) so that the
entire loop will fit in one i-cache line.

To support this, getPrefLoopAlignment has been made virtual, and can be
provided with an optional MachineLoop* so the target can inspect the loop
before answering the query. The default behavior, as before, is to return the
value set with setPrefLoopAlignment. MachineBlockPlacement now queries the
target for each loop instead of only once per function. There should be no
functional change for other targets.

llvm-svn: 225117

Volatile reads are side-effecting operations, but in the general case of access through a volatile-qualified type, we're not certain of the underlying object's side-effects on access.

Treat volatile accesses as "maybe" instead of "definite" side effects for the purposes of warning on evaluations in an unevaluated context. No longer diagnose on idiomatic code like:

int * volatile v;
(void)sizeof(*v);

llvm-svn: 225116

Most modern PowerPC cores prefer that functions and loops start on
16-byte-aligned boundaries (*), so instruct block placement, etc. to make this
happen. The branch selector has also been adjusted so account for the extra
nops that might now be inserted before loop headers.

(*) Some cores actually prefer other alignments for small loops, but that will
    be addressed in a follow-up commit.

llvm-svn: 225115

Make sure they all have llvm_unreachable on the default path out of the switch. Remove unnecessary "default: break". Remove a 'return' after unreachable. Fix some indentation.

llvm-svn: 225114

llvm-svn: 225113

llvm-svn: 225112

llvm-svn: 225111

llvm-svn: 225110

We would sometimes leave the out-param APInts untouched while going
through computeKnownBits.  While I don't know of a way to trigger a bug
involving this in practice, it goes against the overall design of
computeKnownBits.

Found via code inspection.

llvm-svn: 225109

[asan/tracing] extend the test a bit more, simplify the tracing code, add a guard page to trace array, fix the trace IDs before dumping

llvm-svn: 225108

llvm-svn: 225107

Newer POWER cores, and the A2, support the cmpb instruction. This instruction
compares its operands, treating each of the 8 bytes in the GPRs separately,
returning a 'mask' result of 0 (for false) or -1 (for true) in each byte.

Code generation support is added, in the form of a PPCISelDAGToDAG
DAG-preprocessing routine, that recognizes patterns close to what the
instruction computes (either exactly, or related by a constant masking
operation), and generates the cmpb instruction (along with any necessary
constant masking operation). This can be expanded if use cases arise.

llvm-svn: 225106

This adjusts the inputs to be compatible with armv7-windows-msvc as well as
armv7-windows-itanium.  NFC.

llvm-svn: 225105

ARM NT assumes a THUMB only environment.  As such, any address that is detected
as residing in an executable section is adjusted to have its bottom bit set to
indicate THUMB in case of a mode exchange.

Although the testing here seems insufficient (missing the negative cases) the
existing test cases for the IMAGE_REL_ARM_{ADDR32,MOV32T} are relevant as they
ensure that we do not incorrectly set the bit.

llvm-svn: 225104

llvm-svn: 225103

It is not needed since we FileCheck for the warning and -Werror itself can end up
unused.

llvm-svn: 225102

This should fix the last bots.

llvm-svn: 225100

[X86] Disassembler support for move to/from %rax with a 32-bit memory offset is REX.W and AdSize prefix are both present.

llvm-svn: 225099

llvm-svn: 225098

FunctionPassManager. These never got documented, likely due to the
clutter of this header file. This fixes another problem people noticed
when they started trying to use the new pass manager.

I've also used this to document the aspirational constraints I would
like to hold passes to. I don't really have a better place to document
such things at this point, but eventually will probably create a proper
.rst file and page for the LLVM pass infrastructure that carries such
high-level concerns.

llvm-svn: 225097

llvm-svn: 225096

On OS X a .s file is preprocessed, it is not on linux, which is why the warning was still
showing up on linux but not OS X.

llvm-svn: 225095

concept-based polymorphism in the pass manager to a separate header.

I got feedback from someone reading the code and trying to use it that
this was really making it hard to dive in and start using these APIs and
that makes a lot of sense.

This only requires a moderate amount of gymnastics to separate in this
way, namely rinsing the PreservedAnalysis object through a template
argument in a few places so that it is dependent and we only examine it
on instantiation.

llvm-svn: 225094

It is somewhat common for CFLAGS to be used with .s files. We were
already ignoring -flto. This patch just does the same for -fno-lto.

llvm-svn: 225093

llvm-svn: 225092

un-XFAILing the test XFAIL'd in r225086 after it regressed in r225083.

llvm-svn: 225090

Unfortunately, MSVC does not indicate to the driver what target is being used.
This means that we cannot correctly select the target architecture for the
clang_rt component.  This breaks down when targeting windows with the clang
driver as opposed to the clang-cl driver.  This should fix the native ARM
buildbot tests.

llvm-svn: 225089