This patch fixes some ASAN unittest failures on FreeBSD. See the
cfe-commits email thread for r290169 for more on those.

According to the LangRef, the allocsize attribute only tells us about
the number of bytes that exist at the memory location pointed to by the
return value of a function. It does not necessarily mean that the
function will only ever allocate. So, we need to be very careful about
treating functions with allocsize as general allocation functions. This
patch makes us fully conservative in this regard, though I suspect that
we have room to be a bit more aggressive if we want.

This has a FIXME that can be fixed by a relatively straightforward
refactor; I just wanted to keep this patch minimal. If this sticks, I'll
come back and fix it in a few days.

llvm-svn: 290397

Reviewers: eugenis

Subscribers: kubabrecka, dberris, llvm-commits

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

llvm-svn: 290396

Extract out two large lambdas into top level member functions.

llvm-svn: 290395

Summary:
This change rewrites a core component in the ImplicitNullChecks pass for
greater simplicity since the original design was over-complicated for no
good reason.  Please review this as essentially a new pass.  The change
is almost NFC and I've added a test case for a scenario that this new
code handles that wasn't handled earlier.

The implicit null check pass, at its core, is a code hoisting transform.
It differs from "normal" code transforms in that it speculates
potentially faulting instructions (by design), but a lot of the usual
hazard detection logic (register read-after-write etc.) still applies.
We previously detected hazards by keeping track of registers defined and
used by machine instructions over an instruction range, but that was
unwieldy and did not actually confer any performance benefits.  The
intent was to have linear time complexity over the number of machine
instructions considered, but it ended up being N^2 is practice.

This new version is more obviously O(N^2) (with N capped to 8 by
default) in hazard detection.  It does not attempt to be clever in
tracking register uses or defs (the previous cleverness here was a
source of bugs).

Once this is checked in, I'll extract out the `IsSuitableMemoryOp` and
`CanHoistLoadInst` lambda into member functions (they're too complicated
to be inline lambdas) and do some other related NFC cleanups.

Reviewers: reames, anna, atrick

Subscribers: mcrosier, llvm-commits

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

llvm-svn: 290394

Summary: We setup these interceptors twice which hangs test on windows.

Reviewers: eugenis

Subscribers: llvm-commits, kubabrecka

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

llvm-svn: 290393

Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.

There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.

This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.

This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.

Differential...

This is necessary for the distribution targets which assume that
each component has an install target. This also moves the CMake
macros into a separate file akin to other LLVM projects.

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

llvm-svn: 290391

llvm-svn: 290390

llvm-svn: 290389

Accidentally re-defined the variable instead of setting it. Oops!

llvm-svn: 290388

I missed those in my previous commit (r290378).

llvm-svn: 290387

This patch adds support for YAML<->DWARF for debug_info sections.

This re-lands r290147, reverted in 290148, re-landed in r290204 after fixing the issue that caused bots to fail (thank you UBSan!), and reverted again in r290209 due to failures on big endian systems.

After adding support for preserving endianness, this should be good now.

llvm-svn: 290386

We're only testing the addressing mode on the stores; we don't
need to load/store pointers we can simply pass/return.

llvm-svn: 290385

Use a dummy private function with inline asm calls instead of module
level asm blocks for CFI jumptables.

The main advantage is that now jumptable codegen can be affected by
the function attributes (like target_cpu on ARM). Module level asm
gets the default subtarget based on the target triple, which is often
not good enough.

This change also uses asm constraints/arguments to reference
jumptable targets and aliases directly. We no longer do asm name
mangling in an IR pass.

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

llvm-svn: 290384

Bot URL:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/2505

llvm-svn: 290383

Summary:
According https://reviews.llvm.org/D27659#625093 WRAP adds confusing stack
frame.

Reviewers: eugenis

Subscribers: kubabrecka, llvm-commits

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

llvm-svn: 290382

This patch adds support to the macho<->yaml tools for preserving endianness in MachO structures and DWARF data.

llvm-svn: 290381

We used to not check generic vregs, but that is actually a mistake given
nothing in the GlobalISel pipeline is going to fix the constraints on
target specific instructions. Therefore, the target has to have them
right from the start.

llvm-svn: 290380

Target specific instructions have requirements that are not compatible
with what we want to test here. Namely, target specific instructions
must have their operands properly mapped on register classes.

llvm-svn: 290379

We have long switched from size to type.

llvm-svn: 290378

The InstructionSelect pass will not look at target specific instructions
since they are already selected. As a result, the operands of target
specific instructions must be properly constrained, because it is not
going to fix them.

This fixes invalid register classes on call instruction.

llvm-svn: 290377

When generic virtual registers get constrained, because of a use on a
target specific operation for instance, we end up with regular virtual
registers with a type and that's perfectly fine.

llvm-svn: 290376

This is going to be needed to be able to constraint register class on
target specific instruction while the RegBankSelect pass did not run
yet.

llvm-svn: 290375

Move the logic to constraint register from InstructionSelector to a
utility function. It will be required by other passes in the GlobalISel
pipeline.

llvm-svn: 290374

Summary: Make thread local quarantine size an option so it can be turned off to save memory.

Reviewers: eugenis

Patch by Alex Shlyapnikov.

Subscribers: kubabrecka, llvm-commits

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

llvm-svn: 290373

Canonicalize a select with a constant to the false side. This
enables more instruction shrinking opportunities since an
inline immediate can be used for the false side of v_cndmask_b32_e32.

This seems to usually be better but causes some code size regressions
in some tests.

llvm-svn: 290372

Summary:
Warm up ASAN caches in ThreadedQuarantineTest to get more predictable
incremental heap memory usage measurements.

Reviewers: eugenis

Patch by Alex Shlyapnikov.

Subscribers: aemerson, kubabrecka, llvm-commits

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

llvm-svn: 290371

Reviewers: chandlerc, hfinkel, echristo, iteratee

Subscribers: mehdi_amini, nemanjai, llvm-commits

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

llvm-svn: 290370

Recommitted after formal approval.

LLVM's JIT is now the foundation of dynamic-compilation features for many languages. Clang also has low-level support for dynamic compilation (ASTImporter and ExternalASTSource, notably). How the compiler is set up for dynamic parsing is generally left up to individual clients, for example LLDB's C/C++/Objective-C expression parser and the ROOT project.

Although this arrangement offers external clients the flexibility to implement dynamic features as they see fit, the lack of an in-tree client means that subtle bugs can be introduced that cause regressions in the external clients but aren't caught by tests (or users) until much later. LLDB for example regularly encounters complicated ODR violation scenarios where it is not immediately clear who is at fault.

Other external clients (notably, Cling) rely on similar functionality, and another goal is to break this functionality up into composable parts so that any client can be built easily on top of Clang without requiring extensive additional code.

I propose that the parts required to build a simple expression parser be added to Clang. Initially, I aim to have the following features:

A piece that looks up external declarations from a variety of sources (e.g., from previous dynamic compilations, from modules, or from DWARF) and uses clear conflict resolution rules to reconcile differences, with easily understood errors. This functionality will be supported by in-tree tests.
A piece that works hand in hand with the LLVM JIT to resolve the locations of external declarations so that e.g. variables can be redeclared and (for high-performance applications like DTrace) external variables can be accessed directly from the registers where they reside.
This commit adds a tester that parses a sequence of source files and then uses them as source data for an expression. External references are resolved using an ExternalASTSource that responds to name queries using an ASTImporter. This is the setup that LLDB uses, and the motivating reason for MinimalImport in ASTImporter. When complete, this tester will implement the first of the above goals.

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

llvm-svn: 290367

llvm-svn: 290366

This is a succeeding patch of https://reviews.llvm.org/D22840 to address the
issue when a value to be merged into an int64 pair is in a different BB. Redoing
the store splitting in CodeGenPrepare so we can match the pattern across multiple
BBs and move some instructions into the same BB. We still keep the code in dag
combine so that we can catch cases that show up after DAG combining runs.

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

llvm-svn: 290365

program

Offload related code is not quite ready yet, but some simple examples
must not crash the compiler. Patch fixes the problem in offloading code
with exceptions.

llvm-svn: 290364

This is for splitMergedValStore in DAG Combine to share the target query interface
with similar logic in CodeGenPrepare.

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

llvm-svn: 290363

Revert "[XRay][AArch64] An attempt to fix test patching-unpatching.cc by flushing the instruction cache after code modification"

This reverts commit r290354, as it broke the build. We need to make sure
this builds on AArch64 before committing again.

llvm-svn: 290362

Follow up to D27209 fix, this patch now properly handles single transient
instruction in basic block.

Patch by Aleksandar Beserminji.

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

llvm-svn: 290361

llvm-svn: 290360

This patch fixes use of incorrect `%zi` to format a plain `int`, and using
`%llu` to format a `uint64_t`. The fix is to use the new typesafe
`llvm::Formatv` based API.

Differential Revision: https://reviews.llvm.org/D28028
Subscribers: lldb-commits

llvm-svn: 290359

COFF has a 2**16 section limit, and on Win64, every COMDAT function
creates at least 3 sections: .text, .pdata, and .xdata. For MSVC, we
enable bigobj on a file-by-file basis, but GCC appears to hit the limit
on different files.

Fixes PR25953

llvm-svn: 290358

compiler-rt uses it in its lit tests.

llvm-svn: 290357

llvm-svn: 290356