rather than relying on the pass object.

This one is a bit annoying, but will pay off. First, supporting this one
will make the next one much easier, and for utilities like LoopSimplify,
this is moving them (slowly) closer to not having to pass the pass
object around throughout their APIs.

llvm-svn: 226396

Code review suggestion by Eric Christopher.

llvm-svn: 226395

interface, removing Pass from its interface.

This also makes those analyses optional so that passes which don't even
preserve these (or use them) can skip the logic entirely.

llvm-svn: 226394

Update for tests failing due to improvements in clang's column information for aggregate expressions

llvm-svn: 226393

optionally updated by MergeBlockIntoPredecessors.

No functionality changed, just refactoring to clear the way for the new
pass manager.

llvm-svn: 226392

Instead of querying the pass every where we need to, do that once and
cache a pointer in the pass object. This is both simpler and I'm about
to add yet another place where we need to dig out that pointer.

llvm-svn: 226391

Just as r225956 did for scalar expressions (CGExprScalar::Visit), do the
same for complex expressions.

llvm-svn: 226390

llvm-svn: 226389

Just as r225956 did for scalar expressions (CGExprScalar::Visit), do the
same for aggregate expressions.

llvm-svn: 226388

from LoopInfoBase<...>, removing the need for the awkward getBase()
dance.

llvm-svn: 226387

accepting a Pass and querying it for analyses.

This is necessary to allow the utilities to work both with the old and
new pass managers, and I also think this makes the interface much more
clear and helps the reader know what analyses the utility can actually
handle. I plan to repeat this process iteratively to clean up all the
pass utilities.

llvm-svn: 226386

cleaner to derive from the generic base.

Thise removes a ton of boiler plate code and somewhat strange and
pointless indirections. It also remove a bunch of the previously needed
friend declarations. To fully remove these, I also lifted the verify
logic into the generic LoopInfoBase, which seems good anyways -- it is
generic and useful logic even for the machine side.

llvm-svn: 226385

Refactor test so it's not lazily emitted on a global, simplifying ordering when more test cases are added

llvm-svn: 226384

Recommit r225083 (reverted in r225361) now that calls to aggregate initializers from in class non-static data members are explicitly attributed to the desired line.

The code setting the debug location being removed here was accidentally
leaking a location into the call to the non-static data member's ctor
call. Without it the call had no location and could cause assertion
failures if it was inlined. Now that it has a location (and a correct
one at that) this code should hopefully be no longer needed.

It's possible of course that other parts of the debug info are also
relying on the debug locations being set here to leak to where they're
needed - so we might see the same assertions again & will have to
investigate what the dependence was/is. But the chances are good that
any of those are debug info line table quality bugs we've just not found
yet anyway - so it'll be good to flush them out.

llvm-svn: 226383

This was causing some trouble for otherwise dead code removed in r225085
(reverted in r225361). The location being set for function arguments was
leaking out to the call which wasn't setting its own location (so a
quality bug turned into a crasher with r225085). Fix this so r225085 can
be recommitted.

llvm-svn: 226382

llvm-svn: 226381

llvm-svn: 226380

unused variables in a no-asserts build.

I've fixed this by putting the entire loop behind an #ifndef as it
contains nothing other than asserts.

llvm-svn: 226377

This was dead even before I refactored how we initialized it, but my
refactoring made it trivially dead and it is now caught by a Clang
warning. This fixes the warning and should clean up the -Werror bot
failures (sorry!).

llvm-svn: 226376

logic.

In one place we would try to check for the difference between integers
even if we were missing one of the integers. This would eventually end
up reading uninitialized data out of the APSInt objects. The fix is to
short circuit the sameness test when we don't have integers on both
sides.

This fixes a test failure I was seeing with MSan. Not sure whether other
bots were seeing it or not, but yay MSan. In particular the feature to
very carefully track origins back through stores throughout the program
was invaluable.

llvm-svn: 226375

preparation for the new pass manager.

llvm-svn: 226374

a LoopInfoWrapperPass to wire the object up to the legacy pass manager.

This switches all the clients of LoopInfo over and paves the way to port
LoopInfo to the new pass manager. No functionality change is intended
with this iteration.

llvm-svn: 226373

llvm-svn: 226372

llvm-svn: 226371

llvm-svn: 226370

R11's status is the same under both the PPC64 ELF V1 and V2 ABIs: it is
reserved for use as an "environment pointer" for compilation models that
require such a thing. We don't, we also don't need a second scratch register,
and because we support only "local" patchpoint call targets, we might as well
let R11 be used for anyregcc patchpoints.

llvm-svn: 226369

Setting the maximum read size in FlagHandlerInclude to 2^15 might be a good
default, but causes the read to fail on systems with a page size larger than
that (ReadFileToBuffer(...) will fail if the maximum allowed size is less than
the value returned by GetPageSizeCached()). For example, on my PPC64/Linux
system, GetPageSizeCached() returns 2^16. In case the page size is larger, use
that instead.

llvm-svn: 226368

llvm-svn: 226367

llvm-svn: 226366

Clang currently crashes on

    class C {
      C() = default;
      C() = delete;
    };

My cunning plan for fixing this was to change the `if (!FnD)` in
Parser::ParseCXXInlineMethodDef() to `if (!FnD || FnD->isInvalidDecl)` – but
alas, the second constructor decl wasn't marked as invalid.  This lets
Sema::MergeFunctionDecl() return true on function redeclarations, which leads
to them being marked invalid.

This also improves error messages when functions are redeclared.

llvm-svn: 226365

llvm-svn: 226364

llvm-svn: 226363

This function returns a URI of the resource that the connection is connected to. This is especially important for connections established by accepting a connection from a remote host.

Also added implementations for ConnectionMachPort, ConnectionSharedMemory, 
Also fixed up some documentation in Connection::Write
Renamed ConnectionFileDescriptorPosix::SocketListen to ConnectionFileDescriptorPosix::SocketListenAndAccept
Fixed a log message in Socket.cpp

Differential Review: http://reviews.llvm.org/D7026

llvm-svn: 226362

Destructors have a special treatment in getFunctionLinkage. Instead of
duplicating the logic, check the resulting linkage.

llvm-svn: 226361

Loading 2 2x32-bit float vectors into the bottom half of a 256-bit vector
produced suboptimal code in AVX2 mode with certain IR combinations.

In particular, the IR optimizer folded 2f32 + 2f32 -> 4f32, 4f32 + 4f32
(undef) -> 8f32 into a 2f32 + 2f32 -> 8f32, which seems more canonical,
but then mysteriously generated rather bad code; the movq/movhpd combination
didn't match.

The problem lay in the BUILD_VECTOR optimization path. The 2f32 inputs
would get promoted to 4f32 by the type legalizer, eventually resulting
in a BUILD_VECTOR on two 4f32 into an 8f32. The BUILD_VECTOR then, recognizing
these were both half the output size, concatted them and then produced
a shuffle. However, the resulting concat + shuffle was more complex than
it should be; in the case where the upper half of the output is undef, we
probably want to generate shuffle + concat instead.

This enhancement causes the vector_shuffle combine step to recognize this
suboptimal pattern and correct it. I included it there instead of in BUILD_VECTOR
in case the same suboptimal pattern occurs for other reasons.

This results in the optimizer correctly producing the optimal movq + movhpd
sequence for all three variations on this IR, even with AVX2.

I've included a test case.

Radar link: rdar://problem/19287012
Fix for PR 21943.

From: Fiona Glaser <fglaser@apple.com>
llvm-svn: 226360

llvm-svn: 226359

llvm-svn: 226358

llvm-svn: 226357

llvm-svn: 226356

llvm-svn: 226353