Normally we can only make sense of the content of a PDB in terms
of streams and blocks, but in some cases it may be useful to dump
bytes at a specific absolute file offset.  For example, if you
know that some interesting data is at a particular location and
you want to see some surrounding data.

llvm-svn: 306146

This breaks passing of aligned function arguments.

llvm-svn: 306145

This patch contains a pass that transforms CBZ/CBNZ/TBZ/TBNZ instructions into a
conditional branch (Bcc), when the NZCV flags can be set for "free". This is
preferred on targets that have more flexibility when scheduling Bcc
instructions as compared to CBZ/CBNZ/TBZ/TBNZ (assuming all other variables are
equal). This can reduce register pressure and is also the default behavior for
GCC.

A few examples:

 add w8, w0, w1  -> cmn w0, w1             ; CMN is an alias of ADDS.
 cbz w8, .LBB_2  -> b.eq .LBB0_2           ; single def/use of w8 removed.

 add w8, w0, w1  -> adds w8, w0, w1        ; w8 has multiple uses.
 cbz w8, .LBB1_2 -> b.eq .LBB1_2

 sub w8, w0, w1       -> subs w8, w0, w1   ; w8 has multiple uses.
 tbz w8, #31, .LBB6_2 -> b.ge .LBB6_2

In looking at all current sub-target machine descriptions, this transformation
appears to be either positive or neutral.

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

llvm-svn: 306144

Commit r306010 adjusted the condition as follows:

-  if (Is64Bit) {
+  if (!STI.isTargetWin32()) {

The intent was to preserve the behavior on all Windows platforms
but extend the behavior on 64-bit Windows platforms to every
other one. (Before r306010, emitStackProbeCall only ever executed
when emitting code for Windows triples.)

Unfortunately,
  if (Is64Bit && STI.isOSWindows())
is not the same as
  if (!STI.isTargetWin32())
because of the way isTargetWin32() is defined:

  bool isTargetWin32() const {
    return !In64BitMode && (isTargetCygMing() ||
                            isTargetKnownWindowsMSVC());
  }

In practice this broke the JIT tests on 32-bit Windows, which did not
satisfy the new condition:

    LLVM :: ExecutionEngine/MCJIT/2003-01-15-AlignmentTest.ll
    LLVM :: ExecutionEngine/MCJIT/2003-08-15-AllocaAssertion.ll
    LLVM :: ExecutionEngine/MCJIT/2003-08-23-RegisterAllocatePhysReg.ll
    LLVM :: ExecutionEngine/MCJIT/test-loadstore.ll
    LLVM :: ExecutionEngine/OrcMCJIT/2003-01-15-AlignmentTest.ll
    LLVM :: ExecutionEngine/OrcMCJIT/2003-08-15-AllocaAssertion.ll
    LLVM :: ExecutionEngine/OrcMCJIT/2003-08-23-RegisterAllocatePhysReg.ll
    LLVM :: ExecutionEngine/OrcMCJIT/test-loadstore.ll

because %esp was not updated correctly. The failures are only visible
on a MSVC 2017 Debug build, for which we do not have bots.

llvm-svn: 306142

The goal here is to make it possible to display absolute
file offsets when dumping byets from an MSF.  The problem is
that when dumping bytes from an MSF, often the bytes will
cross a block boundary and encounter a discontinuity.  We
can't use the normal formatBinary() function for this because
this would just treat the sequence as entirely ascending, and
not account out-of-order blocks.

This patch adds a formatMsfData() function to our printer, and
then uses this function to improve the output of the -stream-data
command line option for dumping bytes from a particular stream.

Test coverage is also expanded to make sure to include all possible
scenarios of offsets, sizes, and crossing block boundaries.

llvm-svn: 306141

It causes an extra pass of the machine verifier to be added to the pass
manager, and causes test/CodeGen/Generic/llc-start-stop.ll to fail.

llvm-svn: 306140

I'm not sure yet why this wouldn't fail in the simple case,
but clearly I used the wrong value type with:
https://reviews.llvm.org/rL306040

...and the bug manifests with:
https://bugs.llvm.org/show_bug.cgi?id=33560

llvm-svn: 306139

Check on slow/fast unaligned memory targets

llvm-svn: 306138

We were already applying the same rules to dllimport function pointers.
David Majnemer added that logic back in r211677 to fix PR20130.  We
failed to extend that logic to non-virtual member function pointers,
which are basically function pointers in a struct with some extra
offsets.

Fixes PR33570.

llvm-svn: 306137

llvm-svn: 306135

Summary: Reported by coverity, I don't know how to provide a test.

Reviewers: zturner

Subscribers: lldb-commits, emaste

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

llvm-svn: 306134

llvm-svn: 306133

During the construction of MemoryAccesses in ScopBuilder, BasicBlocks
were used in function parameters, assuming that the ScopStmt an be
directly derived from it. This won't be true anymore once we split
BasicBlocks into multiple ScopStmt. As a preparation for such a change
in the future, we instead pass the ScopStmt and avoid the use of
getStmtFor().

There are two occasions where a kind of mapping from BasicBlock to
ScopStmt is still required.

1. Get the statement representing the incoming block of a `PHINode`
   using `getLastStmtOf`.

2. One statement is required to write a scalar to be readable by those
   which need it. This is most often the statement which contains its
   definition, which we get using `getStmtFor(Instruction*)`.

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

llvm-svn: 306132

llvm-svn: 306131

llvm-svn: 306130

llvm-svn: 306129

llvm-svn: 306128

Summary:
Add value completion support for options which are defined in
CC1Options.td, because we only handled options in Options.td.

Reviewers: ruiu, v.g.vassilev, teemperor

Subscribers: llvm-commits

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

llvm-svn: 306127

This is useful when an upper limit on the cache size needs to be
controlled independently of the amount of the amount of free space.

One use case is a machine with a large number of cache directories
(e.g. a buildbot slave hosting a large number of independent build
jobs). By imposing an upper size limit on each cache directory,
users can more easily estimate the server's capacity.

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

llvm-svn: 306126

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

llvm-svn: 306125

llvm-svn: 306124

Add missing -### to the driver to ensure that we dont try to run the
actual command.  The host may not support the IAS.  Should fix the SCEI
buildbots.

llvm-svn: 306123

This is essentially just a BinaryStreamRef packaged with an
offset and the logic for reading one is no different than the
logic for reading a BinaryStreamRef, except that we save the
current offset.

llvm-svn: 306122

llvm-svn: 306121

It was trying to do too many things. The basic lumping together of values for
legalization purposes is now handled by G_MERGE_VALUES. More complex things
involving gaps and odd sizes are handled by G_INSERT sequences.

llvm-svn: 306120

G_SEQUENCE is going away soon so as a first step the MachineIRBuilder needs to
be taught how to emulate it with alternatives. We use G_MERGE_VALUES where
possible, and a sequence of G_INSERTs if not.

llvm-svn: 306119

Summary: visitSwitchInst should not take INT_MAX when Cost is negative. Instead of INT_MAX , we also use a valid upperbound cost when overflow occurs in Cost.

Reviewers: hans, echristo, dmgreen

Reviewed By: dmgreen

Subscribers: mcrosier, javed.absar, llvm-commits, eraman

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

llvm-svn: 306118

This reverts the use of TargetLowering::prepareVolatileOrAtomicLoad
introduced by r196905.  Nothing in the semantics of the "volatile"
keyword or the definition of the z/Architecture actually requires
that volatile loads are preceded by a serialization operation, and
no other compiler on the platform actually implements this.

Since we've now seen a use case where this additional serialization
causes noticable performance degradation, this patch removes it.

The patch still leaves in the serialization before atomic loads,
which is now implemented directly in lowerATOMIC_LOAD.  (This also
seems overkill, but that can be addressed separately.)

llvm-svn: 306117

Currently, autocompleted options are displayed in the same order as we
wrote them in .td files. This patch sort them out in clang so that they
are sorted alphabetically. This should improve usability.

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

llvm-svn: 306116

Restore the `-gz` option to the driver with some minor tweaks to handle
the additional case for `-Wa,--compress-debug-sections`.

This intends to make the compression of the debug information
controllable from the driver.  The following is the behaviour:

  -gz           enable compression (ambiguous for format, will default to zlib-gnu)
  -gz=none      disable compression
  -gz=zlib-gnu  enable compression (deprecated GNU style zlib compression)
  -gz=zlib      enable compression (zlib based compression)

Although -Wa,-compress-debug-sections works, it should be discouraged
when using the driver to invoke the assembler.  However, we permit the
assembler to accept the GNU as style argument --compress-debug-sections
to maintain compatibility.

Note, -gz/-gz= does *NOT* imply -g.  That is, you need to additionally
specific -g for debug information to be generated.

llvm-svn: 306115

llvm-svn: 306114

llvm-svn: 306113

Reviewers: arsenm

Reviewed By: arsenm

Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, igorb, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 306112

dependent initializer"

It caused buildbot failures such as this one:
http://bb.pgr.jp/builders/test-clang-msc-x64-on-i686-linux-RA/builds/3777/steps/test_clang/logs/Clang%20%3A%3A%20Index__ctor-init-source-loc.cpp

llvm-svn: 306111

r306109 was supposed to make this change, but I committed the wrong version.

llvm-svn: 306110

The command-line params override the target setting in the file itself, so delete that.
Also, remove the cpu and arch because those don't matter and neither does the OS specification in the triple.

llvm-svn: 306109

Added AVX1 tests and merged AVX1/AVX2/AVX512 checks where possible

llvm-svn: 306107

The isBarrier/isTerminator flags have been removed from the SystemZ trap
instructions, so that tests do not fail with EXPENSIVE_CHECKS. This was just
an issue at -O0 and did not affect code output on benchmarks.

(Like Eli pointed out: "targets are split over whether they consider their
"trap" a terminator; x86, AArch64, and NVPTX don't, but ARM, MIPS, PPC, and
SystemZ do. We should probably try to be consistent here.". This is still the
case, although SystemZ has switched sides).

SystemZ now returns true in isMachineVerifierClean() :-)

These Generic tests have been modified so that they can be run with or without
EXPENSIVE_CHECKS: CodeGen/Generic/llc-start-stop.ll and
CodeGen/Generic/print-machineinstrs.ll

Review: Ulrich Weigand, Simon Pilgrim, Eli Friedman
https://bugs.llvm.org/show_bug.cgi?id=33047
https://reviews.llvm.org/D34143

llvm-svn: 306106

The single exit block allowed in runtime unrolling is guaranteed to be
the Latch's successor, so rename it as LatchExitBlock.

llvm-svn: 306105

Use triple and attribute only for consistency 

llvm-svn: 306104