llvm-svn: 340863

[llvm-mca] Initialize each element in vector TimelineView::UsedBuffers to a default invalid buffer descriptor. NFCI

Also change the default buffer size for UsedBuffer entries to -1 (i.e. "unknown
size"). No functional change intended.

llvm-svn: 340830

[llvm-mca][TimelineView] Force the same number of executions for every entry in the 'wait-times' table.

This patch also uses colors to highlight problematic wait-time entries.
A problematic entry is an entry with an high wait time that tends to match (or
exceed) the size of the scheduler's buffer.

Color RED is used if an instruction had to wait an average number of cycles
which is bigger than (or equal to) the size of the underlying scheduler's
buffer.
Color YELLOW is used if the time (in cycles) spend waiting for the
operands or pipeline resources is bigger than half the size of the underlying
scheduler's buffer.
Color MAGENTA is used if an instruction does not consume buffer resources
according to the scheduling model.

llvm-svn: 340825

[llvm-mca] Pass an instruction reference when notifying event listeners about reserved/released buffer resources. NFC

llvm-svn: 340821

This patch removes the MSBuild warnings about options that
clang-cl ignores.  It also adds several additional fields to
the LLVM Configuration options page.  The first is that it
adds support for LLD!  To give the user flexibility though,
we don't want to force LLD to always-on, and if we're not
forcing LLD then we might as well not force clang-cl either.
So we add options that can enable or disable lld, clang-cl,
or any combination of the two.  Whenever one is disabled,
it falls back to the Microsoft equivalent.

Additionally, for each of clang-cl and lld-link, we add a new
configuration setting that allows Additional Options to be
passed for that specific tool only.  This is similar to the
C/C++ > Command Line > Additional Options entry box, but
it serves the use case where a user switches back and forth
between the toolsets in their vcxproj, but where cl.exe
won't accept some options that clang-cl will.  In this case
you can pass those options in the clang-cl additional options
and whenever clang-cl is disabled (or the other toolset is
selected entirely), those options won't get passed at all.

llvm-svn: 340780

Normally we force Unix line endings in the repository, but since these are Windows files which are consumed by Microsoft tools that we don't have the source of, we should probably err on the side of caution and force CRLF.

llvm-svn: 340776

llvm-svn: 340768

Summary:
This patch introduces llvm-mca as a library.  The driver (llvm-mca.cpp), views, and stats, are not part of the library. 
Those are separate components that are not required for the functioning of llvm-mca.

The directory has been organized as follows:
All library source files now reside in:
  - `lib/HardwareUnits/` - All subclasses of HardwareUnit (these represent the simulated hardware components of a backend).
      (LSUnit does not inherit from HardwareUnit, but Scheduler does which uses LSUnit).  
  - `lib/Stages/` - All subclasses of the pipeline stages.
  - `lib/` - This is the root of the library and contains library code that does not fit into the Stages or HardwareUnit subdirs.

All library header files now reside in the `include` directory and mimic the same layout as the `lib` directory mentioned above.

In the (near) future we would like to move the library (include and lib) contents from tools and into the core of llvm somewhere.
That change would allow various analysis and optimization passes to make use of MCA  functionality for things like cost modeling.

I left all of the non-library code just where it has always been, in the root of the llvm-mca directory. 
The include directives for the non-library source file have been updated to refer to the llvm-mca library headers.
I updated the llvm-mca/CMakeLists.txt file to include the library headers, but I made the non-library code
explicitly reference the library's 'include' directory.  Once we eventually (hopefully) migrate the MCA library
components into llvm the include directives used by the non-library source files will be updated to point to the
proper location in llvm.

Reviewers: andreadb, courbet, RKSimon

Reviewed By: andreadb

Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits

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

llvm-svn: 340755

llvm-svn: 340754

Before this patch, the SchedulerStatistics only printed the maximum number of
buffer entries consumed in each scheduler's queue at a given point of the
simulation.

This patch restructures the reported table, and adds an extra field named
"Average number of used buffer entries" to it.
This patch also uses different colors to help identifying bottlenecks caused by
high scheduler's buffer pressure.

llvm-svn: 340746

This is a bit awkward in a handful of places where we didn't even have
an instruction and now we have to see if we can build one. But on the
whole, this seems like a win and at worst a reasonable cost for removing
`TerminatorInst`.

All of this is part of the removal of `TerminatorInst` from the
`Instruction` type hierarchy.

llvm-svn: 340701

This time I should be preserving history of the ResourceManager changes.

llvm-svn: 340668

Choosing to revert the change and do it again, hopefully preserving the history
of the changes by using svn copy instead of simply creating a new file from the
contents within Scheduler.

llvm-svn: 340661

llvm-svn: 340659

This (partially) fixes a regression introduced by
https://reviews.llvm.org/D43945 / r327399, which parallelized
DwarfLinker. This patch avoids parsing and allocating the memory for
all input DIEs up front and instead only allocates them in the
concurrent loop in the AnalyzeLambda. At the end of the loop the
memory from the LinkContext is cleared again.

This reduces the peak memory needed to link the debug info of a
non-modular build of the Swift compiler by >3GB.

rdar://problem/43444464

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

llvm-svn: 340650

llvm-svn: 340645

When used in cross-DSO mode, CFI will generate calls to special functions rather than trap instructions.  For example, instead of generating

if (!InlinedFastCheck(f))
  abort();
call *f

CFI generates

if (!InlinedFastCheck(f))
  __cfi_slowpath(CallSiteTypeId, f);
call *f

This patch teaches cfi-verify to recognize calls to __cfi_slowpath and abort and treat them as trap functions.

In addition to normal symbols, we also parse the dynamic relocations to handle cross-DSO calls in libraries.

We also extend cfi-verify to recognize other patterns that occur using cross-DSO.  For example, some indirect calls are not guarded by a branch to a trap but instead follow a call to __cfi_slowpath.  For example:

if (!InlinedFastCheck(f))
  call *f
else {
  __cfi_slowpath(CallSiteTypeId, f);
  call *f
}

In this case, the second call to f is not marked as protected by the current code.  We thus recognize if indirect calls directly follow a call to a function that will trap on CFI violations and treat them as protected.

We also ignore indirect calls in the PLT, since on AArch64 each entry contains an indirect call that should not be protected by CFI, and these are labeled incorrectly when debug information is not present.

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

llvm-svn: 340612

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

llvm-svn: 340611

Per LLVM's CommandGuide, llvm-profdata show -text is supposed to produce
textual output that can be passed as input to further llvm-profdata
invocations. This previously didn't work for two reasons:

1) -text was not sufficient to enable the machine-readable text format output;
instead, -text was effectively ignored if -counts was not also specified. (With
this patch, -counts is instead ignored if -text is specified, because the
machine-readable text format always includes counts.)

2) When the input data was an IR-level profile, the :ir marker was missing from
the output, resulting in a text format output that would not be usable as
profiling data due to function hash mismatches.

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

llvm-svn: 340592

llvm-svn: 340570

* Set (not reset) the strategy in Scheduler::setCustomStrategyImpl()

llvm-svn: 340566

Thanks to @waltl for reporting this issue.

I have also added an assert to check for invalid null strategy objects, and I
have reworded a couple of code comments in Scheduler.h

llvm-svn: 340545

With this patch, users can now customize the pipeline selection strategy for
scheduler resources. The resource selection strategy can be defined at processor
resource granularity. This enables the definition of different strategies for
different hardware schedulers.

To override the strategy associated with a processor resource, users can call
method ResourceManager::setCustomStrategy(), and pass a 'ResourceStrategy'
object in input.

Class ResourceStrategy is an abstract class which declares virtual method
`ResourceStrategy::select()`. Method select() is meant to implement the actual
strategy; it is responsible for picking the next best resource from a set of
available pipeline resources.  Custom strategy must simply override that method.

By default, processor resources are associated with instances of
'DefaultResourceStrategy'.  A 'DefaultResourceStrategy' internally implements a
simple round-robin selector. For more details, please refer to the code comments
in Scheduler.h.

llvm-svn: 340536

Both DWARFDebugLine and DWARFDebugAddr used the same callback mechanism
for handling recoverable errors. They both implemented similar warn() function
to be used as such callbacks.

In this revision we get rid of code duplication and move this warn() function
to DWARFContext as DWARFContext::dumpWarning().

Reviewers: lhames, jhenderson, aprantl, probinson, dblaikie, JDevlieghere

Reviewed By: jhenderson

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

llvm-svn: 340528

The format is the same as in ELF: a sequence of ULEB128-encoded
symbol indexes.

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

llvm-svn: 340499

There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.

This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.

With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.

llvm-svn: 340435

llvm-svn: 340431

llvm-svn: 340422

[llvm-mca] Improved code comments and moved some method definitions from Scheduler.h to Scheduler.cpp. NFC

llvm-svn: 340395

Summary: This is to be consistent with lld behavior since rLLD340364.

Reviewers: tejohnson

Reviewed By: tejohnson

Subscribers: steven_wu, eraman, mehdi_amini, inglorion, dexonsmith, llvm-commits

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

llvm-svn: 340380

llvm-svn: 340340

llvm-svn: 340316

The constructor of Scheduler now accepts a SchedulerStrategy object, which is
used internally by method Scheduler::select() to drive the instruction selection
process.

The goal of this patch is to enable the definition of custom selection
strategies while reusing the same algorithms implemented by class Scheduler.
The motivation is that, on some targets, the default strategy may not well
approximate the selection logic in the hardware schedulers.

This patch also adds the ability to pass a ResourceManager object to the
constructor of Scheduler. This gives a bit more flexibility to the design, and
potentially it allows to expose processor resources to SchedulerStrategy
objects.

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

llvm-svn: 340314

llvm-svn: 340305

This should unbreak the buildbots.

llvm-svn: 340274

The goal of this patch is to simplify the Scheduler's interface in preparation
for D50929.
Some methods in the Scheduler's interface should not be exposed to external
users, since their presence makes it hard to both understand, and extend the
Scheduler's interface.

This patch removes the following two methods from the public Scheduler's API:
 - reclaimSimulatedResources()
 - updatePendingQueue()
Their logic has been migrated to a new method named 'cycleEvent()'.

Methods 'updateIssuedSet()' and 'promoteToReadySet()' still exist. However,
they are now private members of class Scheduler.

This simplifies the interaction with the Scheduler from the ExecuteStage.

llvm-svn: 340273

llvm-svn: 340241

Summary: Before, llvm-strip accepted a second argument but it would just be ignored.

Reviewers: alexshap, jhenderson, paulsemel

Reviewed By: alexshap

Subscribers: jakehehrlich, rupprecht, llvm-commits

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

llvm-svn: 340229

llvm-svn: 340227

llvm-svn: 340221