Reference::target() never returns a nullptr, so NULL check
is not needed and is more harmful than doing nothing.
No functionality change.

llvm-svn: 210008

This patch can handles following cases from http://nondot.org/sabre/LLVMNotes/InstCombine.txt
  "((1 << X) & 7) == 0" ==> "X > 2"
  "((1 << X) & 7) != 0" ==> "X < 3".

Differential Revision: http://reviews.llvm.org/D3678

llvm-svn: 210007

if ((x & C) == 0) x |= C becomes x |= C
if ((x & C) != 0) x ^= C becomes x &= ~C
if ((x & C) == 0) x ^= C becomes x |= C
if ((x & C) != 0) x &= ~C becomes x &= ~C
if ((x & C) == 0) x &= ~C becomes nothing

Differential Revision: http://reviews.llvm.org/D3777

llvm-svn: 210006

llvm-svn: 210005

No functional changes.

llvm-svn: 210004

Amend r210001 to use the classic fallback order behaviour if the requested
graphing program isn't found.

llvm-svn: 210003

Preparation for <string_view>. More helper functions that can be shared between <string> and <string_view>. No functionality change

llvm-svn: 210002

Replace the crufty build-time configure checks for program paths with
equivalent runtime logic.

This lets users install graphing tools as needed without having to reconfigure
and rebuild LLVM, while eliminating a long chain of inappropriate compile
dependencies that included GUI programs and the windowing system.

Additional features:

 * Support the OS X 'open' command to view graphs generated by any of the
   Graphviz utilities. This is an alternative to the Graphviz OS X UI which is
   no longer available on Mountain Lion.

 * Produce informative log output upon failure to indicate which programs can
   be installed to view graphs.

Ping me if this doesn't work for your particular environment.

llvm-svn: 210001

Instruction::isIdenticalToWhenDefined(): Check getNumOperands() in advance of std::equal(op) to appease MSVC Debug build.

MSVC Debug build is confused with (possibly invalid) op_begin(), if op_begin() == op_end().

llvm-svn: 210000

Since we cannot yet use variadic templates, add a specialisation for
6-parameters to format.  This is motivated by a need for the additional
parameter for formatting information for an unwind decoder for Windows on ARM.

llvm-svn: 209999

Introduce the support structures necessary to deal with the Windows ARM EH data.
These definitions are extremely aggressive about assertions to aid future use
for generation of the entries and subsequent decoding.

The names for the various fields are meant to reflect the names used by the
Visual Studio toolchain to aid communication.

Due to the complexity in reading a few of the values, there are a couple of
additional utility functions to decode the information.

In general, there are two ways to encode the unwinding information:
- packed, which places the data inline into the
  _IMAGE_ARM_RUNTIME_FUNCTION_ENTRY structure.
- unpacked, which places the data into auxiliary structures placed into the
  .xdata section.

The set of structures allow reading of data in either encoding, with the minor
caveat that epilogue scopes need to be decoded manually by constructing the
structure from the data returned by the RuntimeFunction structure.

These definitions are meant for read-only access at the current point as the
first use of them will be to decode the exception information.

llvm-svn: 209998

Wrong patch got committed (this one isn't ready for prime time).

This reverts commit r209996.

llvm-svn: 209997

We should treat tentative definitions as undefined for the purpose of
ODR-use linkage checking.

This broke somewhere around r149731 when tests were disabled.

Note that test coverage for these diagnostics is generally lacking due to a
separate issue (PR19910: Don't suppress unused/undefined warnings when there
are errors).

llvm-svn: 209996

llvm-svn: 209995

This is not yet supported for production builds but can already produce working
binaries on OS X and Linux with clang and gcc.

The intention is to improve support to the point where it can integrate with
the LLVM runtime platform, cover all platforms, runtime/release build
configurations and run the tests.

Patch by Jack Howarth!

llvm-svn: 209994

llvm-svn: 209993

http://llvm.org/bugs/show_bug.cgi?id=18498

This code was resulting in a crash:

auto L = [](auto ... v) { };
L.operator()<int>(3);

The reason is that the partially-substituted-pack is incorrectly retained within the current-instantiation-scope during template-argument-finalization, and because lambda's are local, there parent instantiation scopes are merged, which leads to the expansion-pattern being retained in the finalized specialization.

This patch ensures that once we have finalized deduction of a parameter-pack, we remove the partially-substituted-pack so that it doesn't cause CheckParameterPacksForExpansion to incorrectly inform the caller that it needs to retain the expansion pattern.


Thanks to Richard Smith for the review!

http://reviews.llvm.org/D2135

llvm-svn: 209992

Remove redundant -fno-stack-protector run with openbsd.
Add -target to the -fstack-protector tests so they pass on openbsd.

Patch by Brad Smith.

llvm-svn: 209991

Reviewed at http://reviews.llvm.org/D3968

llvm-svn: 209990

This patch updates IntelJITEventListener.cpp to account for revision 206654, which removed some methods from DILineInfo.

llvm-svn: 209989

llvm-svn: 209988

Arrange .ctors/.dtors sections in the following order:
  .ctors from crtbegin.o or crtbegin?.o
  .ctors from regular object files
  .ctors.* (sorted) from regular object files
  .ctors from crtend.o or crtend?.o

This order is specific for MIPS traget. For example, on X86
the .ctors.* sections are merged into the .init_array section.

llvm-svn: 209987

Place constants into .rdata if targeting ELF or COFF/PE.  This should be
functionally identical, however, the data would be placed into a different
section.  This is purely a cleanup change.

llvm-svn: 209986

Make the whitespace a bit more uniform in the various assembly routines.  This
also makes the assembly files a bit more uniform on the ARM side by explicitly
stating that it is using the unified syntax and that the contents of the code is
in the text section (or segment).  No functional change.

llvm-svn: 209985

This was previously committed in r209680 and reverted in r209683 after
it caused sanitizer builds to crash.

The issue seems to be that the DebugLoc associated with dbg.value IR
intrinsics isn't necessarily accurate. Instead, we duplicate the
DIVariables and add an InlinedAt field to them to record their
location.

We were using this InlinedAt field to compute the LexicalScope for the
variable, but not using it in the abstract DbgVariable construction and
mapping. This resulted in a formal parameter to the current concrete
function, correctly having no InlinedAt information, but incorrectly
having a DebugLoc that described an inlined location within the
function... thus an abstract DbgVariable was created for the variable,
but its DIE was never constructed (since the LexicalScope had no such
variable). This DbgVariable was silently ignored (by testing for a
non-null DIE on the abstract DbgVariable).

So, fix this by using the right scoping information when constructing
abstract DbgVariables.

In the long run, I suspect we want to undo the work that added this
second kind of location tracking and fix the places where the DebugLoc
propagation on the dbg.value intrinsic fails. This will shrink debug
info (by not duplicating DIVariables), make it more efficient (by not
having to construct new DIVariable metadata nodes to try to map back to
a single variable), and benefit all instructions.

But perhaps there are insurmountable issues with DebugLoc quality that
I'm unaware of... I just don't know how we can't /just keep the DebugLoc
from the dbg.declare to the dbg.values and never get this wrong/.

Some history context:

http://llvm.org/viewvc/llvm-project?view=revision&revision=135629
http://llvm.org/viewvc/llvm-project?view=revision&revision=137253

llvm-svn: 209984

The tests were correctly getting skipped but the targets still mistakenly got
built.

llvm-svn: 209983

llvm-svn: 209982

llvm-svn: 209981

llvm-svn: 209980

These patterns are already handled in the instruction definition.

llvm-svn: 209979

With recent changes, this is now a compatible language extension and can be
safely enabled with -ms-extensions instead of requiring the full
-ms-compatibility MSVC drop-in mode. As such we can now also emit an extension
warning under -Wmicrosoft to help users port their code.

llvm-svn: 209978

DAG cycle detection is only enabled with ENABLE_EXPENSIVE_CHECKS.  However we
can run it just before we would crash in order to provide more informative
diagnostics.

Now in addition to the "Overran sorted position" message we also get the Node
printed if a cycle was detected.

Tested by building several configs: Debug+Assert, Debug+Assert+Check (this is
ENABLE_EXPENSIVE_CHECKS), Release+Assert and Release.  Also tried that the
AssignTopologicalOrder assert produces the expected results.

llvm-svn: 209977

Pass the DAG down to checkForCycles from all callers where we have it.  This
allows target-specific nodes to be printed properly.

Also print some missing newlines.

llvm-svn: 209976

Prefer the decl in SelectionDAGNodes.h because it's used there and
SelectionDAG.h includes SelectionDAGNodes.h.

llvm-svn: 209975

llvm-svn: 209974

Handle "X + ~X" -> "-1" in the function Value *Reassociate::OptimizeAdd(Instruction *I, SmallVectorImpl<ValueEntry> &Ops);
This patch implements:
TODO: We could handle "X + ~X" -> "-1" if we wanted, since "-X = ~X+1".

Patch by Rahul Jain!

Differential Revision: http://reviews.llvm.org/D3835

llvm-svn: 209973

The XFAILs in r208840 were too general. They were meant to only apply
to testing when use_system_lib was set.

llvm-svn: 209972

llvm-svn: 209971

Resolves an old FIXME.

No callers depend on this giving the right answer so I haven't been able to
cook up a useful test case.

llvm-svn: 209970

isExternCTemplate() and getLanguageLinkageTemplate() have nothing to do with
templates despite the dubious naming scheme.

llvm-svn: 209969