Reapply r290077.

Authors: pelikan

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

llvm-svn: 290330

the bots unhappy.

llvm-svn: 290329

I was staring at these and didn't realize these were module-layer
proxies as opposed to some other layer. Justin and I have a plan to
rename things to make the names themselves much easier to reason about,
but I at least want the CHECK lines to be precise for now.

llvm-svn: 290328

declarations.

We're using a custom class here instead of the helper template, these
bits just didn't get deleted when the other bits did get deleted. This
was found by a really nice MSVC warning about explicitly instantiating
a template where some member functions aren't defined and thus can't be
instantiatied.

llvm-svn: 290327

Merge all VFS mapped files inside -ivfsoverlay inputs into the vfs
overlay provided by the crash reproducer. This is the last missing piece
to allow crash reproducers to fully work with user frameworks; when
combined with headermaps, it allows clang to find additional frameworks.

rdar://problem/27913709

llvm-svn: 290326

from the old pass manager in the new one.

I'm not trying to support (initially) the numerous options that are
currently available to customize the pass pipeline. If we end up really
wanting them, we can add them later, but I suspect many are no longer
interesting. The simplicity of omitting them will help a lot as we sort
out what the pipeline should look like in the new PM.

I've also documented to the best of my ability *why* each pass or group
of passes is used so that reading the pipeline is more helpful. In many
cases I think we have some questionable choices of ordering and I've
left FIXME comments in place so we know what to come back and revisit
going forward. But for now, I've left it as similar to the current
pipeline as I could.

Lastly, I've had to comment out several places where passes are not
ported to the new pass manager or where the loop pass infrastructure is
not yet ready. I did at least fix a few bugs in the loop pass
infrastructure uncovered by running the full pipeline, but I didn't want
to go too far in this patch -- I'll come back and re-enable these as the
infrastructure comes online. But I'd like to keep the comments in place
because I don't want to lose track of which passes need to be enabled
and where they go.

One thing that seemed like a significant API improvement was to require
that we don't build pipelines for O0. It seems to have no real benefit.

I've also switched back to returning pass managers by value as at this
API layer it feels much more natural to me for composition. But if
others disagree, I'm happy to go back to an output parameter.

I'm not 100% happy with the testing strategy currently, but it seems at
least OK. I may come back and try to refactor or otherwise improve this
in subsequent patches but I wanted to at least get a good starting point
in place.

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

llvm-svn: 290325

When DwarfExpression is emitting a fragment that is located in a
register and that fragment is smaller than the register, and the
register must be composed from sub-registers (are you still with me?)
the last DW_OP_piece operation must not be larger than the size of the
fragment itself, since the last piece of the fragment could be smaller
than the last subregister that is being emitted.

rdar://problem/29779065

llvm-svn: 290324

Previously, you had to call initDemangledSyms() before accessing DemangledSyms.
Now getDemangledSyms() initializes it and then returns it. So it is now less easy
to use it in a wrong way.

llvm-svn: 290323

... so it becomes available to DIExpressionCursor.

llvm-svn: 290322

llvm-svn: 290321

llvm-svn: 290320

Modify getStyle to use vfs::FileSystem::makeAbsolute just like FS.addFile does,
rather than sys::fs::make_absolute. The latter gets the CWD from the platform,
while the former expects it to be set by the client, causing a mismatch when
converting relative paths to absolute.

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

llvm-svn: 290319

llvm-svn: 290318

There are helpers for testing for constant or constant build_vector,
and for splat ConstantFP vectors, but not for a constantfp or
non-splat ConstantFP vector.

llvm-svn: 290317

No tests because these aren't currently used anywhere.

llvm-svn: 290316

Print the fully qualified names for the overload candidates.  This makes
it easier to tell what the ambiguity is.  Especially if a template
is instantiated after a using namespace, it will not inherit the
namespace where it was declared.  The specialization will give a message
about a partial order being ambiguous for the same (unqualified) name,
which does not help identify the failure.

Addresses PR31450!

llvm-svn: 290315

Size goes from 72B to 64B per entry.

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

llvm-svn: 290314

FMA is canonicalized to constant in the middle operand. Do
the same so fmad matches and avoid an extra combine step.

llvm-svn: 290313

llvm-svn: 290312

Extend the existing fadd/fsub->fmad combines to produce
FMA if allowed.

llvm-svn: 290311

twice, in finalization of template argumetn deduction.

llvm-svn: 290310

llvm-svn: 290309

llvm-svn: 290308

llvm-svn: 290307

llvm-svn: 290306

Although the result is the same, the intent is much more clear this way:
we care about the architecture we are targeting.  NFC.

llvm-svn: 290305

We can query the Triple and EffectiveTriple from the ToolChain.  Avoid
passing in the argument and query it in the function.  NFC.

llvm-svn: 290304

The parameter to ParsePICOpts passed the effective triple and then used
that in a few places and used the actual triple in others.  This was
slightly confusing.  Rename the parameter to make it more obvious.

llvm-svn: 290303

llvm-svn: 290302

llvm-svn: 290301

llvm-svn: 290300

I don't think this matters because ConstantFP is legal.

llvm-svn: 290299

This is to put the vector into a well defined state. Apparently the state of a
vector after being moved from is valid but unspecified. Found with clang-tidy.

llvm-svn: 290298

This is a recommit of r290149, which was reverted in r290169 due to msan
failures. msan was failing because we were calling
`isMostDerivedAnUnsizedArray` on an invalid designator, which caused us
to read uninitialized memory. To fix this, the logic of the caller of
said function was simplified, and we now have a `!Invalid` assert in
`isMostDerivedAnUnsizedArray`, so we can catch this particular bug more
easily in the future.

Fingers crossed that this patch sticks this time. :)

Original commit message:

This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
  number of bytes handed back to us by malloc/realloc/calloc/any user
  functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
  is OK sometimes. This is why we have a change in
  test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
  unrelated tests. Richard Smith okay'ed this idea some time ago in
  person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
  D26410. Lack of uniquing only really shows up as a problem when
  combined with our new eagerness in the face of const.

llvm-svn: 290297

-256 is a legal indexed address part.

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

llvm-svn: 290296

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

llvm-svn: 290295

The range metadata inserted by NVVMIntrRange is pessimistic, range
metadata already present could be more precise.

llvm-svn: 290294

This patch renumbers the metadata nodes in debug info testcases after
https://reviews.llvm.org/D26769. This is a separate patch because it
causes so much churn. This was implemented with a python script that
pipes the testcases through llvm-as - | llvm-dis - and then goes
through the original and new output side-by side to insert all
comments at a close-enough location.

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

llvm-svn: 290292

Otherwise these records do not survive roundtrips.

llvm-svn: 290291

llvm-svn: 290289