There were some issues surrounding Py2 / Py3 compatibility, but
I've now tested with both Py2 and Py3 and everything seems to
work.

llvm-svn: 313467

It looks like this is going to be non-trivial to get working
in both Py2 and Py3, so for now I'm reverting until I have time
to fully test it under Python 3.

llvm-svn: 313429

This was reverted alongside the revert of the lit/llvm-lit refactor,
but now that that has re-landed, I'm relanding this as well.

llvm-svn: 313426

This is a resubmission of r313270.  It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.

The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config.  If present, it
will generate llvm-lit into the output directory.  Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system.  This supports the use case of
someone installing lit via a package manager.  If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.

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

llvm-svn: 313407

This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.

llvm-svn: 313335

This is breaking due to some changes I forgot to merge in, so I'm
temporarily reverting them until I can re-test that this works.

llvm-svn: 313328

To further reduce duplicate code, this patch introduces a module
that configs can simply import and get access to a lot of useful
functionality such as setting up paths, adding features that are
useful across all projects, and other utility-type functions.

For now this only updates llvm's suite to use this new library,
but subsequent patches will update other projects.

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

llvm-svn: 313325

This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.

A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run.  However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on.  As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.

This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.

This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.

On the other hand, for us it allows us to make many simplifications:

* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
  might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
  on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
  support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
  finding a site config from the main config are now gone.

One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters.  Instead, you need to run
llvm-lit.py.

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

llvm-svn: 313270

llvm-svn: 312427

As discussed on llvm-dev I've implemented the first basic steps towards
llvm-objcopy/llvm-objtool (name pending).

This change adds the ability to copy (without modification) 64-bit
little endian ELF executables that have SHT_PROGBITS, SHT_NOBITS,
SHT_NULL and SHT_STRTAB sections.

Patch by Jake Ehrlich

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

llvm-svn: 309643

llvm-svn: 309241

llvm-svn: 309229

llvm-svn: 309134

llvm-svn: 308685

Summary: Implement parsing and writing of a single xml manifest file.

Subscribers: mgorny, llvm-commits, hiraditya

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

llvm-svn: 308679

Summary:
The capture() function was removed in r306625. This should fix PGO breakages
reported by Michael Zolotukhin.

Reviewers: mzolotukhin

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 307320

Older PDBs don't have this.  Its presence is detected by using
the various "feature" flags that come at the end of the PDB
Stream.  Detect this, and don't try to dump the ID stream if the
features tells us it's not present.

llvm-svn: 305235

Introduce the new feature "abi-breaking-checks" to satisfy -reverse-iterate in llvm/test/Transforms/Util/PredicateInfo/

A few tests in llvm/test/Transforms/Util/PredicateInfo/ are using -reverse-iterate.
The option -reverse-iterate is enabled with +Asserts in usual cases, but it can be turned on/off regardless of LLVM_ENABLE_ASSERTIONS.

I wonder if this were incompatible to https://reviews.llvm.org/D33908 (r304757).

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

llvm-svn: 304851

Modify the --system-libs option in llvm-config to print system libs only
when using static linking. The system libraries are irrelevant when
linking to a shared library since the library has appropriate library
dependencies embedded.

Modify the --system-libs test appropriately to force static linking, and
disable it if static libs are not available (i.e. BUILD_SHARED_LIBS is
enabled).

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

llvm-svn: 291285

Canonicalize all CMake booleans to 0/1 before passing them to lit, to
ensure that the Python side handles all of them consistently
and correctly. 0/1 is a safe choice of values that trigger the same
boolean interpretation in CMake, Python and C++.

Furthermore, using them without quotes improves the chance Python will
explicitly fail when an incorrect value (such as ON/OFF, TRUE/FALSE,
YES/NO) is accidentally passed, rather than silently misinterpreting
the value.

This replaces a lot of different logics spread around lit site files,
attempting to partially reproduce the boolean logic used in CMake
and usually silently failing when an uncommon value was used instead.
In fact, some of them were never working correctly since different
values were assigned in CMake and checked in Python.

The alternative solution could be to create a common parser for CMake
booleans in lit and use it consistently throughout the site files.
However, it does not seem like the best idea to create redundant
implementation of the same logic and have to follow upstream if it ever
is extended to handle more values.

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

llvm-svn: 291284

This is a CMake var which never evaluates to false.

llvm-svn: 289673

llvm-svn: 289663

Summary:
The current test only checks whether ld64 is available, causing tests
to fail when ld64 is avilable but libLTO is not built.

Reviewers: beanz, mehdi_amini

Subscribers: mehdi_amini, llvm-commits

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

llvm-svn: 289662

llvm-svn: 289504

This reverts commit r249937.

llvm-svn: 289502

This program is for testing features that rely on multi-module bitcode files.
It takes a multi-module bitcode file, extracts one of the modules and writes
it to the output file.

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

llvm-svn: 288201

llvm-strings was added to the test dependencies without updating the lit
substitutions.  Synchronise the list.

llvm-svn: 286773

Usage:

  llvm-xray extract <object file> [-o <filename or '-'>]

The tool gets the XRay instrumentation map from an object file and turns
it into YAML.  We first support ELF64 sleds on x86_64 binaries, with
provision for supporting other supported platforms and formats later.

This is the first of a many-part change to fully implement the
`llvm-xray` tool.

We also define a subcommand registration and dispatch mechanism to be
used by other further subcommand implementations for llvm-xray.

Diffusion Revision: https://reviews.llvm.org/D21987

llvm-svn: 285165

Add a OCAML_INSTALL_PATH variable that can be used to control
the install path for OCaml libraries. The new variable defaults to
${OCAML_STDLIB_PATH}, i.e. the OCaml library path obtained from
the OCaml compiler. Install libraries into "llvm" subdirectory.

This fixes two issues:

1. OCaml library directories differ between systems, and 'lib/ocaml' is
incorrect e.g. on amd64 Gentoo where OCaml is installed
in 'lib64/ocaml'. Therefore, obtain the library path from the OCaml
compiler using 'ocamlc -where' (which is already used to set
OCAML_STDLIB_PATH), which is the method used commonly in OCaml packages.

2. The top-level directory is reserved for the standard library, and has
precedence over local directory in search path. As a result, OCaml
preferred the files installed along with previous LLVM version over the
source tree when building a new version, resulting in two versions being
mixed during the build. The new layout is used commonly by other OCaml
packages, and findlib is able to find the LLVM libraries successfully.

Bug: https://bugs.gentoo.org/559134
Bug: https://bugs.gentoo.org/559624

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

llvm-svn: 282895

This adds a copy of the demangler in libcxxabi.

The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.

The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:

    No constexpr.
    No alignas

On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi

My current plan is:

    Commit something like this
    Change lld to use it
    Change lldb to use it as the fallback

    Add a few #ifdefs so that exactly the same file can be used in
    libcxxabi to export abi::__cxa_demangle.

Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.

llvm-svn: 280732

This restores commit r278330, with fixes for a few bot failures:
- Fix a late change I had made to the save temps output file that I
  missed due to existing files sitting on my disk
- Fix a bunch of Windows bot failures with "ambiguous call to overloaded
  function" due to confusion between llvm::make_unique vs
  std::make_unique (preface the new make_unique calls with "llvm::")
- Attempt to fix a modules bot failure by adding a missing include
  to LTO/Config.h.

Original change:

Resolution-based LTO API.

Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol in each object, rather than the combined object as a whole. This will
become increasingly important for use cases such as ThinLTO which require us
to process symbol resolutions in a more complicated way than just adjusting
linkage.

Patch by Peter Collingbourne.

Reviewers: rafael, tejohnson, mehdi_amini

Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits

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

llvm-svn: 278338

This reverts commit r278330.

I made a change to the save temps output that is causing issues with the
bots. Didn't realize this because I had older output files sitting on
disk in my test output directory.

llvm-svn: 278331

Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol in each object, rather than the combined object as a whole. This will
become increasingly important for use cases such as ThinLTO which require us
to process symbol resolutions in a more complicated way than just adjusting
linkage.

Patch by Peter Collingbourne.

Reviewers: rafael, tejohnson, mehdi_amini

Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits

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

Address review comments

llvm-svn: 278330

Add the $arch-registered-target features that clang uses to disable
tests that require a registered backend, so that we can run the sancov
tests on Windows. LLVM's lit suite did not appear to have a per-test way
to do this, and I would rather not split up the sancov tests into
architecture directories.

Split out of https://reviews.llvm.org/D23321

llvm-svn: 278271

COFF doesn't support weak linkage on functions.

llvm-svn: 278162

Followup from r277778, after Mehdi's comments.

Expand %ld64 to perform the necessary preload instead, that way new
tests do not need to worry about setting up DYLD_INSERT_LIBRARIES
themselves.

rdar://problem/24300926

llvm-svn: 277788

Green Dragon's darwin stage2 asan bot fails on some checks:
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check

  test/tools/lto/hide-linkonce-odr.ll
  test/tools/lto/opt-level.ll

ERROR: Interceptors are not working. This may be because
AddressSanitizer is loaded too late (e.g. via dlopen)

To fix this, %ld64 needs to load 'libclang_rt.asan_osx_dynamic.dylib'
before libLTO.dylib, via DYLD_INSERT_LIBRARIES. This won't work by
updating config.environment, since some shim binary in the way scrubs
the env vars. Instead, provide the path to this lib through %asanrtlib,
which can then be used by tests directly with DYLD_INSERT_LIBRARIES.

rdar://problem/24300926

llvm-svn: 277778

For example, stop expanding 'opt' in -passes='require<opt-remark-emit>'.

llvm-svn: 276707

Reviewers: mehdi_amini

Subscribers: llvm-commits

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

llvm-svn: 275214

Reviewers: alexfh, wolfgangp, rengolin

Subscribers: llvm-commits

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

llvm-svn: 274949