There is a memory leak which is detected in some of the sanitizer builds.
MCSymbolWasm contains SmallVectors for holding signature information,
however MCContext doesn't run destructors for MCSymbols, so in cases
where the SmallVectors heap-allocate, the memory is leaked.

llvm-svn: 342707

Summary:
There isn't any actual dependency - there's one #include from CodeGen
but nothing from the header is actually used.

With this change we can use the MCA library from CodeGen without
circular dependencies (e.g. for scheduling).

Reviewers: andreadb

Reviewed By: andreadb

Authored By: orodley

Subscribers: mgorny, gbedwell, llvm-commits

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

llvm-svn: 342706

In my original diff I missed #include "llvm/System/Thing.h" and forgot to update a
reference to .inc files a few lines down. This patch corrects these things as 
they were missed in revision 342500.

llvm-svn: 342705

This is a bit easier to follow than handling the copy and src maps
directly in the pass, and will make upcoming changes to how this is
done easier to follow.

llvm-svn: 342703

Summary:
Implement --version for objcopy and strip.

I think there are LLVM utilities that automatically handle this, but that doesn't seem to work with custom parsing since this binary handles both objcopy and strip, so it uses custom parsing.

This fixes PR38298

Reviewers: jhenderson, alexshap, jakehehrlich

Subscribers: llvm-commits

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

llvm-svn: 342702

This makes WebAssembly build by default, rather than requiring
LLVM_EXPERIMENTAL_TARGETS_TO_BUILD!

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

llvm-svn: 342701

llvm-svn: 342700

Fix DenseSet::ConstIterator pointer/reference typedefs to be const

Patch by Brad Moody!

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

llvm-svn: 342697

https://reviews.llvm.org/D52127

This patch adds the ability to watch for insertions/deletions of
MachineInstructions similar to MachineRegisterInfo.

llvm-svn: 342696

llvm-svn: 342694

Currently, BPF has XADD (locked add) insn support and the
asm looks like:
  lock *(u32 *)(r1 + 0) += r2
  lock *(u64 *)(r1 + 0) += r2
The instruction itself does not have a return value.

At the source code level, users often use
  __sync_fetch_and_add()
which eventually translates to XADD. The return value of
__sync_fetch_and_add() is supposed to be the old value
in the xadd memory location. Since BPF::XADD insn does not
support such a return value, this patch added a PreEmit
phase to check such a usage. If such an illegal usage
pattern is detected, a fatal error will be reported like
  line 4: Invalid usage of the XADD return value
if compiled with -g, or
  Invalid usage of the XADD return value
if compiled without -g.

Signed-off-by: Yonghong Song <yhs@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 342692

Summary: Depends on D52105.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 342691

Summary: Adds the necessary support to lib/ObjectYAML and fixes SIMD
calls to allow the tests to work. Also removes some dead code that
would otherwise have to have been updated.

Reviewers: aheejin, dschuff, sbc100

Subscribers: jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 342689

The suffix tree won't ever consider sequences with a length less than 2.

Therefore, we really ought to not even consider them in the first place.

Also add a FIXME explaining that this should be defined in terms of the size
in B of an outlined call versus the size in B of the MBB.

llvm-svn: 342688

Summary:
AvailableExternal was not handled in isDiscardableIfUnused when isDiscardableIfUnused
was added in r158476. Till it was handled in r247044. This is a NFC.

Reviewers: pcc, tejohnson

Reviewed By: tejohnson

Subscribers: llvm-commits

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

llvm-svn: 342684

Fast-math is irrelevant for these transforms.

llvm-svn: 342683

tryLocalSplit only handles a single use block, but an interval may
have multiple use blocks.  So don't crash in that case.  This fixes
PR38795.

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

llvm-svn: 342682

llvm-svn: 342681

r342631 expanded bitc::METADATA_LOCATION by one element. The bitcode
metadata loader was changed in a backwards-incompatible way, leading to
crashes when disassembling old bitcode:

  assertion: empty() && "PlaceholderQueue hasn't been flushed before being destroyed"
  Assertion failed: (empty() && "PlaceholderQueue hasn't been flushed before being destroyed")

This commit teaches the metadata loader to assume that the newly-added
IsImplicitCode bit is 'false' when not present in old bitcode. I've added a
bitcode compat regression test.

rdar://44645820

llvm-svn: 342678

When you create an outlined function, you know everything you need to know
to decide if debug info should be created. If we emit debug info in
createOutlinedFunction, then we don't need to keep track of every IR function
we create.

llvm-svn: 342677

Summary:
rL323619 marks functions that are calling va_end as not viable for
inlining. This patch reverses that since this va_end doesn't need
access to the vriadic arguments list that are saved on the stack, only
va_start does.

Reviewers: efriedma, fhahn

Reviewed By: fhahn

Subscribers: eraman, haicheng, llvm-commits

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

llvm-svn: 342675

llvm-svn: 342674

llvm-svn: 342670

x86 had 2 versions of peekThroughBitcast. DAGCombiner had 1. Plus, it had a 1-off implementation for the one-use variant.
Move the x86 versions of the code to SelectionDAG, so we don't have different copies of the code. 
No functional change intended.

I'm putting this next to isBitwiseNot() because I am planning to use it in there. Another option is next to the
helpers in the ISD namespace (eg, ISD::isConstantSplatVector()). But if there's no good reason for those to be 
there, I'd prefer to pull other helpers over to SelectionDAG in follow-up steps.

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

llvm-svn: 342669

llvm-svn: 342665

Pass Execution Instrumentation interface enables customizable instrumentation
of pass execution, as per "RFC: Pass Execution Instrumentation interface"
posted 06/07/2018 on llvm-dev@

The intent is to provide a common machinery to implement all
the pass-execution-debugging features like print-before/after,
opt-bisect, time-passes etc.

Here we get a basic implementation consisting of:
* PassInstrumentationCallbacks class that handles registration of callbacks
  and access to them.

* PassInstrumentation class that handles instrumentation-point interfaces
  that call into PassInstrumentationCallbacks.

* Callbacks accept StringRef which is just a name of the Pass right now.
  There were some ideas to pass an opaque wrapper for the pointer to pass instance,
  however it appears that pointer does not actually identify the instance
  (adaptors and managers might have the same address with the pass they govern).
  Hence it was decided to go simple for now and then later decide on what the proper
  mental model of identifying a "pass in a phase of pipeline" is.

* Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies
  on different IRUnits (e.g. Analyses).

* PassInstrumentationAnalysis analysis is explicitly requested from PassManager through
  usual AnalysisManager::getResult. All pass managers were updated to run that
  to get PassInstrumentation object for instrumentation calls.

* Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra
  args out of a generic PassManager's extra args. This is the only way I was able to explicitly
  run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or
  RepeatedPass::run.
  TODO: Upon lengthy discussions we agreed to accept this as an initial implementation
  and then get rid of getAnalysisResult by improving RepeatedPass implementation.

* PassBuilder takes PassInstrumentationCallbacks object to pass it further into
  PassInstrumentationAnalysis. Callbacks registration should be performed directly
  through PassInstrumentationCallbacks.

* new-pm tests updated to account for PassInstrumentationAnalysis being run

* Added PassInstrumentation tests to PassBuilderCallbacks unit tests.
  Other unit tests updated with registration of the now-required PassInstrumentationAnalysis.

  Made getName helper to return std::string (instead of StringRef initially) to fix
  asan builtbot failures on CGSCC tests.

Reviewers: chandlerc, philip.pfaffe
Differential Revision: https://reviews.llvm.org/D47858

llvm-svn: 342664

This test was missed on the last run since I only ran a subset
of them before commiting.

llvm-svn: 342659

llvm-svn: 342658

Summary:
The goal of this patch is to have the same behaviour than gcc-gcov.
Currently the hit counts for a line is the sum of the counts for each block on that line.
The idea is to detect the cycles in the graph of blocks in using the algorithm by Hawick & James.
The count for a cycle is the min of the counts for each edge in the cycle.
Once we've the count for each cycle, we can sum them and add the transition counts of those cycles.

Fix both https://bugs.llvm.org/show_bug.cgi?id=38065 and https://bugs.llvm.org/show_bug.cgi?id=38066

Reviewers: marco-c, davidxl

Reviewed By: marco-c

Subscribers: vsk, lebedev.ri, sylvestre.ledru, dblaikie, llvm-commits

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

llvm-svn: 342657

Some records point to an LF_CLASS, LF_UNION, LF_STRUCTURE, or LF_ENUM
which is a forward reference and doesn't contain complete debug
information. In these cases, we'd like to be able to quickly locate the
full record. The TPI stream stores an array of pre-computed record hash
values, one for each type record. If we pre-process this on startup, we
can build a mapping from hash value -> {list of possible matching type
indices}. Since hashes of full records are only based on the name and or
unique name and not the full record contents, we can then use forward
ref record to compute the hash of what *would* be the full record by
just hashing the name, use this to get the list of possible matches, and
iterate those looking for a match on name or unique name.

llvm-pdbutil is updated to resolve forward references for the purposes
of testing (plus it's just useful).

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

llvm-svn: 342656

Two test cases should have tested 256-bit variants of VANDN zero-idioms instead
of the 128-bit variants.

llvm-svn: 342655

This can be used for combining and in the vectorizers/cost models.

llvm-svn: 342653

llvm-svn: 342650

Summary:
This is to fix PR38984 "InstCombine assertion at vector gep/icmp folding":
https://bugs.llvm.org/show_bug.cgi?id=38984

Reviewers: majnemer, spatel, lattner, lebedev.ri

Reviewed By: lebedev.ri

Subscribers: lebedev.ri, llvm-commits

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

llvm-svn: 342647

Reviewers: javed.absar

Subscribers: tschuett, courbet, llvm-commits

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

llvm-svn: 342646

This can be achieved more generally by combineX86ShufflesRecursively.

llvm-svn: 342645

Summary:
Added function to set a register to a particular value + tests.
Add EFLAGS test, use new setRegTo instead of setRegToConstant.

Reviewers: courbet, javed.absar

Subscribers: llvm-commits, tschuett, mgorny

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

llvm-svn: 342644

All other GCCs look good so far. GCC 5.4 complains about strict
aliasing, so fix that.

llvm-svn: 342643

This can be achieved more generally by combineX86ShufflesRecursively and was causing a fuzz test failure found by Mikael Holmén.

llvm-svn: 342642

This is a trivial refactoring that I'm committing now as it makes a patch I'm 
about to post for review easier to follow. There is some overlap between 
evaluateConstantImm and addExpr in RISCVAsmParser. This patch allows 
evaluateConstantImm to be reused from addExpr to remove this overlap. The 
benefit will be greater when a future patch adds extra code to allows 
immediates to be evaluated from constant symbols (e.g. `.equ CONST, 0x1234`).

No functional change intended.

llvm-svn: 342641