LLD's performance on PGO instrumented Windows binaries was still not
great even with the fix in D56955; out of the 2m41s linker runtime,
around 2 minutes were still being spent in ICF. I looked into this more
closely and discovered that the vast majority of the runtime was being
spent segregating .pdata sections with the following relocation chain:

.pdata -> identical .text -> unique PGO counter (not eligible for ICF)

This patch causes us to perform 2 rounds of relocation hash
propagation, which allows the hash for the .pdata sections to
incorporate the identifier from the PGO counter. With that, the amount
of time spent in ICF was reduced to about 2 seconds. I also found that
the same change led to a significant ICF performance improvement in a
regular release build of Chromium's chrome_child.dll, where ICF time
was reduced from around 1s to around 700ms.

With the same change applied to the ELF linker, median of 100 runs
for lld-speed-test/chrome reduced from 4.53s to 4.45s on my machine.

I also experimented with increasing the number of propagation rounds
further, but I did not observe any further significant performance
improvements linking Chromium or Firefox.

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

llvm-svn: 351899

It turns out that sections in PGO instrumented object files on Windows
contain a large number of relocations pointing to themselves. With
r347429 this can cause many sections to receive the same hash (usually
zero) as a result of a section's hash being xor'ed with itself.

This patch causes the COFF and ELF linkers to avoid this problem
by adding the hash of the relocated section instead of xor'ing it.
On my machine this causes the regressing test case
provided by Mozilla to terminate in 2m41s.

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

llvm-svn: 351898

[llvm-objcopy] Return Error from Buffer::allocate(), [ELF]Writer::finalize(), and [ELF]Writer::commit()

Summary:
This patch changes a few methods to return Error instead of manually calling error/reportError to abort. This will make it easier to extract into a library.

Note that error() takes just a string (this patch also adds an overload that takes an Error), while reportError() takes string + [error/code]. To help unify things, use FileError to associate a given filename with an error. Note that this takes some special care (for now), e.g. calling reportError(FileName, <something that could be FileError>) will duplicate the filename. The goal is to eventually remove reportError() and have every error associated with a file to be a FileError, and just one error handling block at the tool level.

This change was suggested in D56806. I took it a little further than suggested, but completely fixing llvm-objcopy will take a couple more patches. If this approach looks good, I'll commit this and apply similar patche(s) for the rest.

This change is NFC in terms of non-error related code, although the error message changes in one context.

Reviewers: alexshap, jhenderson, jakehehrlich, mstorsjo, espindola

Reviewed By: alexshap, jhenderson

Subscribers: llvm-commits, emaste, arichardson

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

llvm-svn: 351896

llvm-svn: 351895

The splitting pass does not need BFI unless the Module actually has a profile
summary. Do not calcualte BFI unless the summary is present.

For the sqlite3 amalgamation, this reduces time spent in the splitting pass
from 0.4% of the total to under 0.1%.

llvm-svn: 351894

I discussed this with Pavel, who told me there was no real
thought behind this, and had no objection to remove the
attributes.

llvm-svn: 351893

The splitting pass does not need (post)domtrees until after it's found a
cold block. Defer domtree calculation until a cold block is found.

For the sqlite3 amalgamation, this reduces time spent in the splitting
pass from 0.8% of the total to 0.4%.

llvm-svn: 351892

Some member functions of StringRef/SmallVector/StringSwitch
are marked with the `always_inline` attribute. The result
is that  the body of these functions is not emitted, hence the
debugger can't evaluate them (a typical example is
StringRef::size()), even if the code is built with `-O0`.

The main driver behind this was that of getting faster turnaround
when running `check-llvm`. A previous commit clarifies how to
get good performance when running the testsuite, so we can
get rid of the attribute here.

An alternative approach considered was that of using attribute `used`,
but in the end we preferred to not slap yet another attribute on
these functions.

llvm-svn: 351891

Also add debug prints in the default case of the switches in these routines.

Most if not all of the type legalization handlers already do this so this makes promoting floats consistent

llvm-svn: 351890

Thanks to Simon Dardis for the new text.

llvm-svn: 351889

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

llvm-svn: 351888

While reviewing D57058, Louis had some questions about the existing span constructor tests. They were not testing the stuff that they said they were. Updated the tests to test what they should have been doing

llvm-svn: 351887

It might be a bit nicer to use the fancy .legalIf and co. predicates,
but this was requiring more boilerplate and disables the coverage
assertions.

llvm-svn: 351886

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

llvm-svn: 351885

llvm-svn: 351884

If the underlying filesystem does not support mmap system call,
FileOutputBuffer may fail when it attempts to mmap an output temporary
file. This patch handles such situation.

Unfortunately, it looks like it is very hard to test this functionality
without a filesystem that doesn't support mmap using llvm-lit. I tested
this locally by passing an invalid parameter to mmap so that it fails and
falls back to the in-memory buffer. Maybe that's all what we can do.
I believe it is reasonable to submit this without a test.

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

llvm-svn: 351883

For AMDGPU the shift amount is never 64-bit, and
this needs to use a 32-bit shift.

X86 uses i8, but seemed to be hacking around this before.

llvm-svn: 351882

The old diagnostic form of the trace produced by -v and -vv looks
like:

```
check1:1:8: remark: CHECK: expected string found in input
CHECK: abc
       ^
<stdin>:1:3: note: found here
; abc def
  ^~~
```

When dumping annotated input is requested (via -dump-input), I find
that this old trace is not useful and is sometimes harmful:

1. The old trace is mostly redundant because the same basic
   information also appears in the input dump's annotations.

2. The old trace buries any error diagnostic between it and the input
   dump, but I find it useful to see any error diagnostic up front.

3. FILECHECK_OPTS=-dump-input=fail requests annotated input dumps only
   for failed FileCheck calls.  However, I have to also add -v or -vv
   to get a full set of annotations, and that can produce massive
   output from all FileCheck calls in all tests.  That's a real
   problem when I run this in the IDE I use, which grinds to a halt as
   it tries to capture all that output.

When -dump-input=fail|always, this patch suppresses the old trace from
-v or -vv.  Error diagnostics still print as usual.  If you want the
old trace, perhaps to see variable expansions, you can set
-dump-input=none (the default).

Reviewed By: probinson

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

llvm-svn: 351881

Produce a splat build_vector similar to how
SelectionDAG::getConstant does.

llvm-svn: 351880

llvm-svn: 351879

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

llvm-svn: 351878

This fixes warnings like these:

DwarfInstructions.hpp:85:25: warning: implicit conversion
      loses integer precision: 'uint64_t' (aka 'unsigned long long') to
      'libunwind::DwarfInstructions<libunwind::LocalAddressSpace,
      libunwind::Registers_arm>::pint_t' (aka 'unsigned int')
      [-Wshorten-64-to-32]

DwarfInstructions.hpp:88:25: warning: implicit conversion
      loses integer precision: 'uint64_t' (aka 'unsigned long long') to
      'libunwind::DwarfInstructions<libunwind::LocalAddressSpace,
      libunwind::Registers_arm>::pint_t' (aka 'unsigned int')
      [-Wshorten-64-to-32]

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

llvm-svn: 351877

Either adjust the format string to use a more exact type, or add casts
(for cases when printing pointers to structs/objects with a %p
format specifier).

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

llvm-svn: 351876

When built within the llvm runtimes directory, the runtimes
CMakeLists.txt adds the same.

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

llvm-svn: 351875

Adding MC regressions tests to cover the AVX512F_SCALAR isa sets.
This patch is part of a larger task to cover MC encoding of all X86 isa sets started in revision: https://reviews.llvm.org/D39952

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

llvm-svn: 351874

When built within the llvm runtimes directory, the runtimes
CMakeLists.txt adds the same.

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

llvm-svn: 351873

llvm-svn: 351871

Make sample syntax correct.

llvm-svn: 351867

llvm-svn: 351866

rdar://47397214

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

llvm-svn: 351865

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

llvm-svn: 351864

Summary:
I did this for two reasons:
- Using the CMake packages simplifies building LLDB Standalone. This is for two
  reasons: 1) We were doing a decent amount of work that is already done in the
  LLVMConfig.cmake that we want to import, 2) We had to do some manual work to call
  llvm-config, parse its output, and populate variables that the build system
  uses.
- As far as I understand, using llvm-config makes it difficult if not impossible
  to cross-compile LLDB standalone.

Reviewers: sgraenitz, labath, zturner, JDevlieghere, davide, aprantl, stella.stamenova

Subscribers: mgorny, lldb-commits

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

llvm-svn: 351863

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

llvm-svn: 351862

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

llvm-svn: 351861

llvm-svn: 351859

llvm-svn: 351856

Summary:
Enable building libFuzzer with MSVC.

* Don't try to include <endian.h> in FuzzerSHA1.cpp. MSVC
  doesn't have this header, and WINDOWS is always little
  endian (even on ARM)

Subscribers: srhines, mgorny, javed.absar, kristof.beyls

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

llvm-svn: 351855

those of C_RegisterClass. NFCI.

llvm-svn: 351854

llvm-svn: 351853

I was honestly a bit surprised that we didn't do this before. This
patch is to handle "-" as the stdout so that if you pass `-o -` to
lld, for example, it writes an output to stdout instead of file `-`.

I thought that we might want to handle this at a higher level than
FileOutputBuffer, because if we land this patch, we can no longer
create a file whose name is `-` (there's a workaround though; you can
pass `./-` instead of `-`). However, because raw_fd_ostream already
handles `-` as a special file name, I think it's okay and actually
consistent to handle `-` as a special name in FileOutputBuffer.

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

llvm-svn: 351852