This is a precursor to breaking the pass that computes the DominatorTree
apart from the concrete DominatorTree.

llvm-svn: 199103

Changed intrinsics for vrcp14/vrcp28 vrsqrt14/vrsqrt28 - aligned with GCC.

llvm-svn: 199102

support notionally const queries even though they may trigger DFS
numbering updates.

The updating of DFS numbers and tracking of slow queries do not mutate
the observable state of the domtree. They should be const to
differentiate them from the APIs which mutate the tree directly to do
incremental updates.

This will make it possible in a world where the DominatorTree is not
a pass but merely the result of running a pass to derive DominatorTree
from the base class as it was originally designed, removing a huge
duplication of API in DominatorTree.

llvm-svn: 199101

algorithms and datastructures into the fully generic support library,
separating them (almost) entirely from the LLVM IR. This makes the
reliance on domtrees here *much* cleaner.

It might be worthwhile for someone to use extern templates and other
tools to sink a lot more of this code into the .cpp files instead of the
.h files, but leaving that for someone other than me.

llvm-svn: 199096

trees into the Support library.

These are all expressed in terms of the generic GraphTraits and CFG,
with no reliance on any concrete IR types. Putting them in support
clarifies that and makes the fact that the static analyzer in Clang uses
them much more sane. When moving the Dominators.h file into the IR
library I claimed that this was the right home for it but not something
I planned to work on. Oops.

So why am I doing this? It happens to be one step toward breaking the
requirement that IR verification can only be performed from inside of
a pass context, which completely blocks the implementation of
verification for the new pass manager infrastructure. Fixing it will
also allow removing the concept of the "preverify" step (WTF???) and
allow the verifier to cleanly flag functions which fail verification in
a way that precludes even computing dominance information. Currently,
that results in a fatal error even when you ask the verifier to not
fatally error. It's awesome like that.

The yak shaving will continue...

llvm-svn: 199095

Summary:
Pass check names all the way from ClangTidyModule through
ClangTidyCheck and ClangTidyContext to ClangTidyError, and output it in
handleErrors. This allows to find mis-behaving check and disable it easily.

Reviewers: djasper, klimek

Reviewed By: djasper

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2534

llvm-svn: 199094

Very sorry, this was a premature patch that I still need to investigate and
finish off (for some reason beyond me at the moment it doesn't actually fix the
issue in all cases).

This reverts commit r199091.

llvm-svn: 199093

I should have been a politician.

llvm-svn: 199092

There are two attempted optimisations in reMaterializeTrivialDef, trying to
avoid promoting the size of a register too much when rematerializing.
Unfortunately, both appear to be flawed. First, we see if the original register
would have worked, but this is inadequate. Consider:

    v1 = SOMETHING (v1 is QQ)
    v2:Q0 = COPY v1:Q1 (v1, v2 are QQ)
    ...
    uses of v2

In this case even though v2 *could* be used directly as the output of
SOMETHING, this would set the wrong bits of the QQ register involved. The
correct rematerialization must be:

    v2:Q0_Q1 = SOMETHING (v2 promoted to QQQ)
    ...
    uses of v2:Q1_Q2

For the second optimisation, if the correct remat is "v2:idx = SOMETHING" then
we can't necessarily expect v2 itself to be valid for SOMETHING, but we do try
to hunt for a class between v1 and v2 that works. Unfortunately, this is also
wrong:

    v1 = SOMETHING (v1 is QQ)
    v2:Q0_Q1 = COPY v1 (v1 is QQ, v2 is QQQ)
    ...
    uses of v2 as a QQQ

The canonical rematerialization here is "v2:Q0_Q1 = SOMETHING". However current
logic would decide that v2 could be a QQ (no interest is taken in later uses).

This patch, therefore, always accepts the widened register class without trying
to be clever. Generally there is no penalty to this (e.g. in the common GR32 <
GR64 case, expanding the width doesn't matter because it's not like you were
going to do anything else with the high bits of a GR32 register). It can
increase register pressure in cases like the ARM VFP regs though (multiple
non-overlapping but equivalent subregisters). Hopefully this situation is rare
enough that it won't matter.

Unfortunately, no in-tree targets actually expose this as far as I can tell
(there are so few isAsCheapAsAMove instructions for it to trigger on) so I've
been unable to produce a test. It was exposed in our ARM64 SPEC tests though,
and I will be adding a test there that we should be able to contribute
soon(TM).

llvm-svn: 199091

[asan] fix the ppc32 build (by Jakub Jelinek). Note that the LLVM build still builds only for 64-bit PowerPC, and not for 32-bit

llvm-svn: 199090

script.

llvm-svn: 199089

llvm-svn: 199088

llvm-svn: 199087

style, and remove some unnecessary comments (the code is perfectly
self-documenting here). Also clang-format the function declarations as
they wrap cleanly now.

llvm-svn: 199084

IR library in LLVM r199082.

llvm-svn: 199083

directory. These passes are already defined in the IR library, and it
doesn't make any sense to have the headers in Analysis.

Long term, I think there is going to be a much better way to divide
these matters. The dominators code should be fully separated into the
abstract graph algorithm and have that put in Support where it becomes
obvious that evn Clang's CFGBlock's can use it. Then the verifier can
manually construct dominance information from the Support-driven
interface while the Analysis library can provide a pass which both
caches, reconstructs, and supports a nice update API.

But those are very long term, and so I don't want to leave the really
confusing structure until that day arrives.

llvm-svn: 199082

Should fix the build.

llvm-svn: 199081

llvm-svn: 199080

added in LLVM r199078.

llvm-svn: 199079

This moves the old pass creation functionality to its own header and
updates the callers of that routine. Then it adds a new PM supporting
bitcode writer to the header file, and wires that up in the opt tool.
A test is added that round-trips code into bitcode and back out using
the new pass manager.

llvm-svn: 199078

llvm-svn: 199077

It was too late to set BUG_REPORT_URL after configure_file(config.h).
BUG_REPORT_URL in config.h.cmake would be updated at 2nd run of cmake.
It caused many recompilations.

FYI, configure handles BUG_REPORT_URL in llvm side.

llvm-svn: 199076

This lets us round-trip IR in the expected manner with the opt tool.

llvm-svn: 199075

llvm-svn: 199074

llvm-svn: 199073

llvm-svn: 199072

that through the interface rather than a simple bool. This should allow
starting to wire up real output to round-trip IR through opt with the
new pass manager.

llvm-svn: 199071

llvm-svn: 199070

This patch covered 2 more scenarios:

1.  Two operands of shuffle_vector are the same, like
%shuffle.i = shufflevector <8 x i8> %a, <8 x i8> %a, <8 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14>

2. One of operands is undef, like
%shuffle.i = shufflevector <8 x i8> %a, <8 x i8> undef, <8 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14>

After this patch, perm instructions will have chance to be emitted instead of lots of INS.

llvm-svn: 199069

The target specific parser should return `false' if the target AsmParser handles
the directive, and `true' if the generic parser should handle the directive.
Many of the target specific directive handlers would `return Error' which does
not follow these semantics.  This change simply changes the target specific
routines to conform to the semantis of the ParseDirective correctly.

Conformance to the semantics improves diagnostics emitted for the invalid
directives.  X86 is taken as a sample to ensure that multiple diagnostics are
not presented for a single error.

llvm-svn: 199068

Also regroup these flags so that alike flags are next to each other, while
keeping the list still mostly alphabetical.

The help text isn't ideal, but I feel it's less maze-like than
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Preprocessor-Options.html (look
at the entry for '-MMD' and count how many other entries you need to look up
until you know what it does).

And it looks like -M / -MM are mostly an historical accident and most people
use -MD or -MMD for deps tracking these days, so make -M / -MM refer to
-MD / -MMD instead of the other way round.

llvm-svn: 199067

No functionality change.

llvm-svn: 199066

Targets like SPARC and MIPS have delay slots and normally bundle the
delay slot instruction with the corresponding terminator.

Teach isBlockOnlyReachableByFallthrough to find any MBB operands on
bundled terminators so SPARC doesn't need to specialize this function.

llvm-svn: 199061

DynamicASTMatchers/VariantValueTest.cpp: It works with msvcrt since setmode(stderr, O_BINARY) were removed.

llvm-svn: 199059

llvm-svn: 199058

raw_fd_ostream: Don't change STDERR to O_BINARY, or w*printf() (in assert()) would barf wide chars after llvm::errs().

llvm-svn: 199057

llvm-svn: 199055

The canonical documentation in the header is up-to-date.

llvm-svn: 199054

Various attribute flavours are supported in C++98. Make it clear that this
compatibility warning relates specifically to C++11-style generalized
attributes.

llvm-svn: 199053

FIXME: It should be generic to C++11. For now, it is dedicated to mingw-w64.
llvm-svn: 199052