Unit tests were added to verify this functionality keeps working correctly.

Example output for raw hex bytes:
llvm::ArrayRef<uint8_t> Bytes = ...;
llvm::outs() << format_hex_bytes(Bytes);
554889e5 4881ec70 04000048 8d051002
00004c8d 05fd0100 004c8b0d d0020000

Example output for raw hex bytes with offsets:
llvm::outs() << format_hex_bytes(Bytes, 0x100000d10);
0x0000000100000d10: 554889e5 4881ec70 04000048 8d051002
0x0000000100000d20: 00004c8d 05fd0100 004c8b0d d0020000

Example output for raw hex bytes with ASCII with offsets:
llvm::outs() << format_hex_bytes_with_ascii(Bytes, 0x100000d10);
0x0000000100000d10: 554889e5 4881ec70 04000048 8d051002 |UH.?H.?p...H....|
0x0000000100000d20: 00004c8d 05fd0100 004c8b0d d0020000 |..L..?...L..?...|

The default groups bytes into 4 byte groups, but this can be changed to 1 byte:
llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 16 /*NumPerLine*/, 1 /*ByteGroupSize*/);
0x0000000100000d10: 55 48 89 e5 48 81 ec 70 04 00 00 48 8d 05 10 02
0x0000000100000d20: 00 00 4c 8d 05 fd 01 00 00 4c 8b 0d d0 02 00 00

llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 16 /*NumPerLine*/, 2 /*ByteGroupSize*/);
0x0000000100000d10: 5548 89e5 4881 ec70 0400 0048 8d05 1002
0x0000000100000d20: 0000 4c8d 05fd 0100 004c 8b0d d002 0000

llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 8 /*NumPerLine*/, 1 /*ByteGroupSize*/);
0x0000000100000d10: 55 48 89 e5 48 81 ec 70
0x0000000100000d18: 04 00 00 48 8d 05 10 02
0x0000000100000d20: 00 00 4c 8d 05 fd 01 00
0x0000000100000d28: 00 4c 8b 0d d0 02 00 00

https://reviews.llvm.org/D26405

llvm-svn: 286316

As the test change shows, we can increase the critical path by adding
a 'not' instruction, so make sure that we're actually removing an
instruction if we do this transform.

This transform could also cause us to miss folds of min/max pairs.

llvm-svn: 286315

llvm-svn: 286314

Summary:
Previously we'd look at the GVALinkage of whatever FunctionDecl you
happened to be calling.

This is not right.  In the absence of the gnu_inline attribute, to be
handled separately, the function definition determines the function's
linkage.  So we need to wait until we get a def before we can know
whether something is known-emitted.

Reviewers: tra

Subscribers: cfe-commits, rsmith

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

llvm-svn: 286313

<rdar://problem/28273697>

llvm-svn: 286312

The new LLVM runtimes directory requires the same conventions to be
followed across the runtime projects. These changes make libunwind
build under the runtimes subdirectory.

This patch contains the following changes:

* Rename LLVM_CONFIG to LLVM_CONFIG_PATH
* Check if compiler supports C++11 (required by libunwind)

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

llvm-svn: 286308

Summary:
when replacing symbol references in moved namespaces, trying to make the replace
name as short as possible by considering UsingDecl (i.e. UsingShadow) and
UsingDirectiveDecl (i.e. using namespace decl).

Reviewers: hokein

Subscribers: cfe-commits

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

llvm-svn: 286307

Reviewers: zaks.anna, dcoughlin

Subscribers: cfe-commits

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

llvm-svn: 286306

llvm-svn: 286305

Previously support had been added for using CodeViewRecordIO
to read (deserialize) CodeView type records.  This patch adds
support for writing those same records.  With this patch,
reading and writing of CodeView type records finally uses a single
codepath.

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

llvm-svn: 286304

llvm-svn: 286303

if it is more specific than the one in its DW_AT_specification.

If a static member is an array, the translation unit containing the
member definition may have a more specific type (including its length)
than TUs only seeing the class declaration. This patch adds a
DW_AT_type to the member's DW_TAG_variable in addition to the
DW_AT_specification in these cases. The member type in the
DW_AT_specification still shows the more generic type (without the
length) to avoid defeating type uniquing.

The DWARF standard discourages “duplicating” a DW_AT_type in a member
variable definition but doesn’t explicitly forbid it.  Having the more
specific type (with the array length) available is what allows the
debugger to print the contents of a static array member variable.

https://reviews.llvm.org/D26368
rdar://problem/28706946

llvm-svn: 286302

<rdar://problem/28273697>

llvm-svn: 286301

Summary:
There are two variables here that break. This change constrains both of them to
debug builds (via DEBUG() or #ifndef NDEBUG).

Reviewers: bkramer, t.p.northover

Subscribers: mehdi_amini, vkalintiris

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

llvm-svn: 286300

llvm-svn: 286299

Summary: This reverts commit a8804ddd9fe71304b28e5b834d134fe93e568ee0.

Subscribers: cfe-commits, pirama, eugenis, tberghammer, danalbert

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

llvm-svn: 286298

Summary:
This patch uses the same approach added for inline asm in r285513 to
similarly prevent promotion/renaming of locals used or defined in module
level asm.

All static global values defined in normal IR and used in module level asm
should be included on either the llvm.used or llvm.compiler.used global.
The former were already being flagged as NoRename in the summary, and
I've simply added llvm.compiler.used values to this handling.

Module level asm may also contain defs of values. We need to prevent
export of any refs to local values defined in module level asm (e.g. a
ref in normal IR), since that also requires renaming/promotion of the
local. To do that, the summary index builder looks at all values in the
module level asm string that are not marked Weak or Global, which is
exactly the set of locals that are defined. A summary is created for
each of these local defs and flagged as NoRename.

This required adding handling to the BitcodeWriter to look at GV
declarations to see if they have a summary (rather than skipping them
all).

Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to
ensure that an MCAsmParser is available, otherwise the module asm parse
would silently fail. Initialized the asm parser in the opt tool for use
in testing this fix.

Fixes PR30610.

Reviewers: mehdi_amini

Subscribers: johanengelen, krasin, llvm-commits

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

llvm-svn: 286297

This addresses PR30746, <https://llvm.org/bugs/show_bug.cgi?id=30746>. The ASan pass iterates over entry-block instructions and checks each alloca whether it's in NonInstrumentedStaticAllocaVec, which is apparently slow. This patch gathers the instructions to move during visitAllocaInst.

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

llvm-svn: 286296

Summary:
Bug: https://llvm.org/bugs/show_bug.cgi?id=30940

This macro (along with __ANDROID__) should always be defined for Android
targets. We set it to the major (only) version of the Android API being
compiled for. The Android version is able to be set as an integer suffix
for any valid Android target.

Reviewers: danalbert, eugenis

Subscribers: cfe-commits, pirama, eugenis, tberghammer, danalbert

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

llvm-svn: 286295

[BasicAA] Teach BasicAA to handle the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes

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

llvm-svn: 286294

Fix a bug in the calculation of the changed flag introduced in r285488.

llvm-svn: 286293

Thanks to David Blaikie for suggesting this.

llvm-svn: 286292

Summary:
We've had support for auto upgrading old style scalar TBAA access
metadata tags into the "new" struct path aware TBAA metadata for 3 years
now.  The only way to actually generate old style TBAA was explicitly
through the IRBuilder API.  I think this is a good time for dropping
support for old style scalar TBAA.

I'm not removing support for textual or bitcode upgrade -- if you have
IR with the old style scalar TBAA tags that go through the AsmParser orf
the bitcode parser before LLVM sees them, they will keep working as
usual.

Note:

  %val = load i32, i32* %ptr, !tbaa !N
  !N = < scalar tbaa node >

is equivalent to

  %val = load i32, i32* %ptr, !tbaa !M
  !N = < scalar tbaa node >
  !M = !{!N, !N, 0}

Reviewers: manmanren, chandlerc, sunfish

Subscribers: mcrosier, llvm-commits, mgorny

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

llvm-svn: 286291

Summary:
User applications may register hooks in the .CRT$XL* callback list,
which is called very early by the loader. This is very common in
Chromium:
https://cs.chromium.org/search/?q=CRT.XL&sq=package:chromium&type=cs

This has flown under the radar for a long time because the loader
appears to catch exceptions originating from these callbacks. It's a
real problem when you're debugging an asan application, though, since it
makes the program crash early.

The solution is to add our own callback to this list, and sort it very
early in the list like we do elsewhere. Also add a test with such an
instrumented callback, and test that it gets called with asan.

Reviewers: etienneb

Subscribers: llvm-commits, kubabrecka

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

llvm-svn: 286290

After instruction selection we perform some checks on each VReg just before
discarding the type information. These checks were assertions before, but that
breaks the fallback path so this patch moves the logic into the main flow and
reports a better error on failure.

llvm-svn: 286289

I added a "thread-stop-format" to distinguish between the form
that is just the thread info (since the stop printing immediately prints
the frame info) and one with more frame 0 info - which is useful for
"thread list" and the like.

I also added a frame.no-debug boolean to the format entities so you can
print frame information differently between frames with source info and those
without.

This closes https://reviews.llvm.org/D26383.
<rdar://problem/28273697>

llvm-svn: 286288

All tests pass without the first parameter, so I guess we don't need it.

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

llvm-svn: 286287

llvm-svn: 286286

This completes assembler / disassembler support for all BFP
instructions provided by the floating-point extensions facility.
The instructions added here are not currently used for codegen.

llvm-svn: 286285

Add several instructions that operate on the program mask
or the addressing mode.  These are not really needed for
code generation under Linux, but are provided for completeness
for the assembler/disassembler.

llvm-svn: 286284

Add the 16 access registers as LLVM registers.  This allows removing
a lot of special cases in the assembler and disassembler where we
were handling access registers; this can all just use the generic
register code now.

Also add a bunch of instructions to operate on access registers,
for assembler/disassembler use only.  No change in code generation
intended.

llvm-svn: 286283

llvm-svn: 286282

Summary: When moving all code to new.h/cc,  these code also will be formatted based on the given code style.

Reviewers: ioeric

Subscribers: cfe-commits

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

llvm-svn: 286281

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

llvm-svn: 286280

llvm-svn: 286279

Fixes post-commit review comment from r286177.

llvm-svn: 286275

Since IMPLIFIT_DEF instructions are omitted in the output, when the output
of an IMPLICIT_DEF instruction is stackified, the resulting register lacks
an explicit push, leading to a push/pop mismatch. Fix this by converting
such IMPLICIT_DEFs into CONST_I32 0 instructions so that they have explicit
pushes.

llvm-svn: 286274

This is helpful when multiple instructions are inserted.

llvm-svn: 286273

Erasing reverse_iterators is problematic; iterate manually.
While there, keep track of the range of inserted instructions.
It can miss instructions inserted elsewhere, but those are harder
to track.

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

llvm-svn: 286272

For example, it invalidates the domtree, causing assertions
in later passes which need dominator infos. Make it preserve
GlobalsAA, as suggested by Eli.

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

llvm-svn: 286271