[Documentation] Fix problem in docs/SafeStack.rst introduced in r351976.

llvm-svn: 351977

[Documentation] Use HTTPS whenever possible

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

llvm-svn: 351976

[DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target.

Enable full support for the debug info.

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

llvm-svn: 351974

Revert "[DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target."

This reverts commit r351972. Some pieces of the patch was not applied
correctly.

llvm-svn: 351973

[DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target.

Enable full support for the debug info. Recommit to fix the emission of
the not required closing brace.

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

llvm-svn: 351972

Commit D11348: 'Win32 support: wcsnrtombs and mbsnrtowcs don't handle null output buffers correctly' which has been hanging around for a long time

llvm-svn: 351971

[X86] Autogenerate complete checks. NFC

llvm-svn: 351970

Merge similar target diagnostics for interrupt attribute into one; NFC

Patch by Kristina Bessonova!

llvm-svn: 351969

[llvm-symbolizer] Improve compatibility of --functions with GNU addr2line

This fixes https://bugs.llvm.org/show_bug.cgi?id=40072.

GNU addr2line's --functions switch is off by default, has a short alias
of -f, and does not take an argument. This patch changes llvm-symbolizer
to allow the second and third point (changing the default behaviour may
have negative impacts on users). If the option is missing a value, it
now treats it as "linkage".

This change does cause one previously valid command-line to behave
differently. Before --functions <value> was accepted, but now only
--functions=<value> is allowed (as well as --functions). The old
behaviour will result in the value being treated as a positional
argument.

The previous testing for --functions=short has been pulled out into a
new test that also tests the other accepted values and option formats.

Reviewed by: ruiu

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

llvm-svn: 351968

Revert "[DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target."

This reverts commit r351846.

This patch may generate illegal assembly code, see

```
$ ./bin/clang -cc1 -triple nvptx64-nvidia-cuda -aux-triple x86_64-grtev4-linux-gnu -S -disable-free -disable-llvm-verifier -discard-value-names -main-file-name new.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -fmerge-all-constants -mdisable-fp-elim -relaxed-aliasing -no-integrated-as -mpie-copy-relocations -munwind-tables -fcuda-is-device -target-feature +ptx60 -target-cpu sm_35 -dwarf-column-info -debug-info-kind=line-directives-only -dwarf-version=2 -debugger-tuning=gdb -o empty.s -x cuda empty.cc
$  cat empty.s
//
// Generated by LLVM NVPTX Back-End
//

.version 6.0
.target sm_35
.address_size 64

}
```

llvm-svn: 351966

[MC][X86] Correctly model additional operand latency caused by transfer delays from the integer to the floating point unit.

This patch adds a new ReadAdvance definition named ReadInt2Fpu.
ReadInt2Fpu allows x86 scheduling models to accurately describe delays caused by
data transfers from the integer unit to the floating point unit.
ReadInt2Fpu currently defaults to a delay of zero cycles (i.e. no delay) for all
x86 models excluding BtVer2. That means, this patch is only a functional change
for the Jaguar cpu model only.

Tablegen definitions for instructions (V)PINSR* have been updated to account for
the new ReadInt2Fpu. That read is mapped to the the GPR input operand.
On Jaguar, int-to-fpu transfers are modeled as a +6cy delay. Before this patch,
that extra delay was added to the opcode latency. In practice, the insert opcode
only executes for 1cy. Most of the actual latency is actually contributed by the
so-called operand-latency. According to the AMD SOG for family 16h, (V)PINSR*
latency is defined by expression f+1, where f is defined as a forwarding delay
from the integer unit to the fpu.

When printing instruction latency from MCA (see InstructionInfoView.cpp) and LLC
(only when flag -print-schedule is speified), we now need to account for any
extra forwarding delays. We do this by checking if scheduling classes declare
any negative ReadAdvance entries. Quoting a code comment in TargetSchedule.td:
"A negative advance effectively increases latency, which may be used for
cross-domain stalls". When computing the instruction latency for the purpose of
our scheduling tests, we now add any extra delay to the formula. This avoids
regressing existing codegen and mca schedule tests. It comes with the cost of an
extra (but very simple) hook in MCSchedModel.

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

llvm-svn: 351965

[llvm-readelf] Don't suppress static symbol table with --dyn-symbols + --symbols

In r287786, a bug was introduced into llvm-readelf where it didn't print
the static symbol table if both --symbols and --dyn-symbols were
specified, even if there was no dynamic symbol table. This is obviously
incorrect.

This patch fixes this issue, by delegating the decision of which symbol
tables should be printed to the final dumper, rather than trying to
decide in the command-line option handling layer. The decision was made
to follow the approach taken in this patch because the LLVM style dumper
uses a different order to the original GNU style behaviour (and GNU
readelf) for ELF output. Other approaches resulted in behaviour changes
for other dumpers which felt wrong. In particular, I wanted to avoid
changing the order of the output for --symbols --dyn-symbols for LLVM
style, keep what is emitted by --symbols unchanged for all dumpers, and
avoid having different orders of .dynsym and .symtab dumping for GNU
"--symbols" and "--symbols --dyn-symbols".

Reviewed by: grimar, rupprecht

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

llvm-svn: 351960

Fix indentation. NFCI.

llvm-svn: 351958

[IR] Match intrinsic parameter by scalar/vectorwidth

This patch replaces the existing LLVMVectorSameWidth matcher with LLVMScalarOrSameVectorWidth.

The matching args must be either scalars or vectors with the same number of elements, but in either case the scalar/element type can differ, specified by LLVMScalarOrSameVectorWidth.

I've updated the _overflow intrinsics to demonstrate this - allowing it to return a i1 or <N x i1> overflow result, matching the scalar/vectorwidth of the other (add/sub/mul) result type.

The masked load/store/gather/scatter intrinsics have also been updated to use this, although as we specify the reference type to be llvm_anyvector_ty we guarantee the mask will be <N x i1> so no change in behaviour

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

llvm-svn: 351957

[Hexagon] Remove incorrect bit negation

llvm-svn: 351956

[AArch64] Fix out of bounds strlen

CFIInst is not zero-terminated. This is one of more annoying functional
differences between StringRef and ArrayRef.

Found by asan.

llvm-svn: 351955

Re-land rL322538 "Add a value_type to ArrayRef."

llvm-svn: 351954

Move saturated arithmetic intrinsics to other integer intrinsics. NFCI.

They were in the floating point group.

llvm-svn: 351953

Disable test better.

llvm-svn: 351952

[llvm-objdump] - Move common code to a new printRelocation() helper. NFC.

This extracts the common code for printing relocations into a new helper function.

llvm-svn: 351951

[AMDGPU] With XNACK, cannot clause a load with result coalesced with operand

Summary:
With XNACK, an smem load whose result is coalesced with an operand (thus
it overwrites its own operand) cannot appear in a clause, because some
other instruction might XNACK and restart the whole clause.

The clause breaker already realized that an smem that overwrites an
operand cannot appear in a clause, and broke the clause. The problem
that this commit fixes is that the SIFormMemoryClauses optimization
formed a bundle with early clobber, which caused the earlier code that
set up the coalesced operand to be removed as dead.

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

Change-Id: I703c4d5b0bf7d6060222bec491f45c18bb3c0016
llvm-svn: 351950

Disable test added in r351916.

It doesn't pass on Windows:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/3627

FAIL: lld :: ELF/stdout.s (1521 of 1966)
******************** TEST 'lld :: ELF/stdout.s' FAILED ********************
Script:
--
: 'RUN: at line 3';   C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\llvm-mc.EXE -filetype=obj -triple=x86_64-unknown-linux C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\lld\test\ELF\stdout.s -o C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o
: 'RUN: at line 4';   c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\ld.lld.EXE C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o -o - > C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1
: 'RUN: at line 5';   C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\llvm-objdump.EXE -d C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1 | C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\FileCheck.EXE C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\lld\test\ELF\stdout.s
: 'RUN: at line 10';   c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\ld.lld.EXE C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o -o C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2
: 'RUN: at line 11';   diff C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1 C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 3"
$ "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\llvm-mc.EXE" "-filetype=obj" "-triple=x86_64-unknown-linux" "C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\lld\test\ELF\stdout.s" "-o" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o"
$ ":" "RUN: at line 4"
$ "c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\ld.lld.EXE" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o" "-o" "-"
$ ":" "RUN: at line 5"
$ "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\llvm-objdump.EXE" "-d" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1"
$ "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\FileCheck.EXE" "C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\lld\test\ELF\stdout.s"
$ ":" "RUN: at line 10"
$ "c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\ld.lld.EXE" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o" "-o" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2"
$ ":" "RUN: at line 11"
$ "diff" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2"
# command output:
*** C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1
--- C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2
***************
*** 1 ****

llvm-svn: 351949

[llvm-objcopy] [COFF] Error out on use of unhandled options

Prefer erroring out than silently not doing what was requested.

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

llvm-svn: 351948

[llvm-objcopy] [COFF] Fix handling of aux symbols for big objects

The aux symbols were stored in an opaque std::vector<uint8_t>,
with contents interpreted according to the rest of the symbol.

All aux symbol types but one fit in 18 bytes (sizeof(coff_symbol16)),
and if written to a bigobj, two extra padding bytes are written (as
sizeof(coff_symbol32) is 20). In the storage agnostic intermediate
representation, store the aux symbols as a series of coff_symbol16
sized opaque blobs. (In practice, all such aux symbols only consist
of one aux symbol, so this is more flexible than what reality needs.)

The special case is the file aux symbols, which are written in
potentially more than one aux symbol slot, without any padding,
as one single long string. This can't be stored in the same opaque
vector of fixed sized aux symbol entries. The file aux symbols will
occupy a different number of aux symbol slots depending on the type
of output object file. As nothing in the intermediate process needs
to have accurate raw symbol indices, updating that is moved into the
writer class.

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

llvm-svn: 351947

[llvm-objcopy] [COFF] Remove testcase debugging lines. NFC.

These are no longer necessary as the testcase now seems to run fine
on the buildbots that previously failed on this case, after SVN r351934.

llvm-svn: 351946

[HotColdSplitting] Remove unused SSAUpdater.h include (NFC).

llvm-svn: 351945

Mark more tests flaky

Reported on the NetBSD 8 buildbot

llvm-svn: 351944

[clangd] Workaround a test failure after r351941

This should fix failing buildbots.

llvm-svn: 351943

[llvm-objdump] - Move variable. NFC.

It was too far from the place where it is used.

llvm-svn: 351942

[clangd] Fix crash due to ObjCPropertyDecl

With ObjCPropertyDecl, ASTNode.OrigD can be a ObjCPropertyImplDecl
which is not a NamedDecl, leading to a crash since the code
incorrectly assumes ASTNode.OrigD will always be a NamedDecl.

Change by dgoldman (David Goldman)!

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

llvm-svn: 351941

[llvm-objdump] - Split disassembleObject() into two methods. NFCI.

Currently, disassembleObject() is a ~550 lines length function.

This patch splits it into two, where first do all helper objects initializations
and calls the second which does all the rest job.
This is a straightforward split.

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

llvm-svn: 351940

[SystemZ]  Fix test case for buildbot.

llvm-clang-x86_64-expensive-checks-win triggered this assert:

"llvm.dbg.value intrinsic requires a !dbg attachment"

Hopefully, adding reasonable !dbg operands solves this.

llvm-svn: 351939

[ARM] Alter the register allocation order for minsize on Thumb2

Currently in Arm code, we allocate LR first, under the assumption that
it needs to be saved anyway. Unfortunately this has the disadvantage
that it will require any instructions using it to be the longer thumb2
instructions, not the shorter thumb1 ones.

This switches the order when we are optimising for minsize, returning to
the default order so that more lower registers can be used. It can end
up requiring more pushed registers, but on average produces smaller code.

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

llvm-svn: 351938

Mark thread.condition.condvarany/wait_for.pass.cpp as flaky

Reported on the NetBSD 8 buildbot.

llvm-svn: 351937

[llvm-symbolizer] Allow single letter command flags grouping.

Summary: Currently llvm-symbolizer doesn't allow flags combining. This patch allows such grouping behavior just like addr2line. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40304

Reviewers: jhenderson, ruiu

Reviewed By: jhenderson

Subscribers: rupprecht, llvm-commits

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

llvm-svn: 351936

[ARM][CGP] Check trunc type before replacing

In the last stage of type promotion, we replace any zext that uses a
new trunc with the operand of the trunc. This is okay when we only
allowed one type to be optimised, but now its the case that the trunc
maybe needed to produce a more narrow type than the one we were
optimising for. So we need to check this before doing the replacement.

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

llvm-svn: 351935

[llvm-objcopy] [COFF] Clear the unwritten tail of coff_section::Header::Name

This should fix the add-gnu-debuglink test on all buildbots.

llvm-svn: 351934

[DAGCombine] Enable more pre-indexed stores

The current check in CombineToPreIndexedLoadStore is too
conversative, preventing a pre-indexed store when the base pointer
is a predecessor of the value being stored. Instead, we should check
the pointer operand of the store.

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

llvm-svn: 351933

[SLH][AArch64] Remove accidentally retained -debug-only line from test.

llvm-svn: 351932

Reapply: [llvm-objcopy] [COFF] Implement --add-gnu-debuglink

This was reverted since it broke a couple buildbots. The reason
for the breakage is not yet known, but this time, the test has
got more diagnostics added, to hopefully allow figuring out
what goes wrong.

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

llvm-svn: 351931

[SLH] AArch64: correctly pick temporary register to mask SP

As part of speculation hardening, the stack pointer gets masked with the
taint register (X16) before a function call or before a function return.
Since there are no instructions that can directly mask writing to the
stack pointer, the stack pointer must first be transferred to another
register, where it can be masked, before that value is transferred back
to the stack pointer.
Before, that temporary register was always picked to be x17, since the
ABI allows clobbering x17 on any function call, resulting in the
following instruction pattern being inserted before function calls and
returns/tail calls:

mov x17, sp
and x17, x17, x16
mov sp, x17
However, x17 can be live in those locations, for example when the call
is an indirect call, using x17 as the target address (blr x17).

To fix this, this patch looks for an available register just before the
call or terminator instruction and uses that.

In the rare case when no register turns out to be available (this
situation is only encountered twice across the whole test-suite), just
insert a full speculation barrier at the start of the basic block where
this occurs.

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

llvm-svn: 351930

[clangd] Link clangTidy into clangd tests

Patch by Nathan Ridge!

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

llvm-svn: 351929

[SystemZ]  Handle DBG_VALUE instructions in two places in backend.

Two backend optimizations failed to handle cases when compiled with -g, due
to failing to consider DBG_VALUE instructions. This was in
SystemZTargetLowering::emitSelect() and
SystemZElimCompare::getRegReferences().

This patch makes sure that DBG_VALUEs are recognized so that they do not
affect these optimizations.

Tests for branch-on-count, load-and-trap and consecutive selects.

Review: Ulrich Weigand
https://reviews.llvm.org/D57048

llvm-svn: 351928

Fix building sanitizers for MinGW

The /EHsc flag is MSVC specific, not generic to the windows target.

llvm-svn: 351927

[IRCE] Support narrow latch condition for wide range checks

This patch relaxes restrictions on types of latch condition and range check.
In current implementation, they should match. This patch allows to handle
wide range checks against narrow condition. The motivating example is the
following:

  int N = ...
  for (long i = 0; (int) i < N; i++) {
    if (i >= length) deopt;
  }

In this patch, the option that enables this support is turned off by
default. We'll wait until it is switched to true.

Differential Revision: https://reviews.llvm.org/D56837
Reviewed By: reames

llvm-svn: 351926

[doc] Fix svn property for bugprone-parent-virtual-call.rst

llvm-svn: 351925

[ubsan] Check the correct size when sanitizing array new.

We previously forgot to multiply the element size by the array bound.

llvm-svn: 351924

[Pipeliner] Add two pragmas to control software pipelining optimization

#pragma clang loop pipeline(disable)

    Disable SWP optimization for the next loop.
    “disable” is the only possible value.

#pragma clang loop pipeline_initiation_interval(number)

    Set value of initiation interval for SWP
    optimization to specified number value for
    the next loop. Number is the positive value
    greater than 0.

These pragmas could be used for debugging or reducing
compile time purposes. It is possible to disable SWP for
concrete loops to save compilation time or to find bugs
by not doing SWP to certain loops. It is possible to set
value of initiation interval to concrete number to save
compilation time by not doing extra pipeliner passes or
to check created schedule for specific initiation interval.

That is llvm part of the fix

Clang part of fix: https://reviews.llvm.org/D55710

Patch by Alexey Lapshin!

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

llvm-svn: 351923

Revert rCTE351921 to fix documentation geneeration.

Original review: https://reviews.llvm.org/D56945

llvm-svn: 351922

[clang-tidy] Delete obsolete objc-property-declaration options ✂️

Summary:
The `Acronyms` and `IncludeDefaultAcronyms` options were deprecated in
https://reviews.llvm.org/D51832. These options can be removed.

Tested by running the clang-tidy tests.

Reviewers: benhamilton, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: Eugene.Zelenko, xazax.hun, cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 351921

hwasan: Move memory access checks into small outlined functions on aarch64.

Each hwasan check requires emitting a small piece of code like this:
https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#memory-accesses

The problem with this is that these code blocks typically bloat code
size significantly.

An obvious solution is to outline these blocks of code. In fact, this
has already been implemented under the -hwasan-instrument-with-calls
flag. However, as currently implemented this has a number of problems:
- The functions use the same calling convention as regular C functions.
  This means that the backend must spill all temporary registers as
  required by the platform's C calling convention, even though the
  check only needs two registers on the hot path.
- The functions take the address to be checked in a fixed register,
  which increases register pressure.
Both of these factors can diminish the code size effect and increase
the performance hit of -hwasan-instrument-with-calls.

The solution that this patch implements is to involve the aarch64
backend in outlining the checks. An intrinsic and pseudo-instruction
are created to represent a hwasan check. The pseudo-instruction
is register allocated like any other instruction, and we allow the
register allocator to select almost any register for the address to
check. A particular combination of (register selection, type of check)
triggers the creation in the backend of a function to handle the check
for specifically that pair. The resulting functions are deduplicated by
the linker. The pseudo-instruction (really the function) is specified
to preserve all registers except for the registers that the AAPCS
specifies may be clobbered by a call.

To measure the code size and performance effect of this change, I
took a number of measurements using Chromium for Android on aarch64,
comparing a browser with inlined checks (the baseline) against a
browser with outlined checks.

Code size: Size of .text decreases from 243897420 to 171619972 bytes,
or a 30% decrease.

Performance: Using Chromium's blink_perf.layout microbenchmarks I
measured a median performance regression of 6.24%.

The fact that a perf/size tradeoff is evident here suggests that
we might want to make the new behaviour conditional on -Os/-Oz.
But for now I've enabled it unconditionally, my reasoning being that
hwasan users typically expect a relatively large perf hit, and ~6%
isn't really adding much. We may want to revisit this decision in
the future, though.

I also tried experimenting with varying the number of registers
selectable by the hwasan check pseudo-instruction (which would result
in fewer variants being created), on the hypothesis that creating
fewer variants of the function would expose another perf/size tradeoff
by reducing icache pressure from the check functions at the cost of
register pressure. Although I did observe a code size increase with
fewer registers, I did not observe a strong correlation between the
number of registers and the performance of the resulting browser on the
microbenchmarks, so I conclude that we might as well use ~all registers
to get the maximum code size improvement. My results are below:

Regs | .text size | Perf hit
-----+------------+---------
~all | 171619972  | 6.24%
  16 | 171765192  | 7.03%
   8 | 172917788  | 5.82%
   4 | 177054016  | 6.89%

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

llvm-svn: 351920

gn build: Merge r351820.

llvm-svn: 351919

gn build: Merge r351880

llvm-svn: 351918

lld-link: Use just one code path to process associative comdats, reject some invalid associated comdats

Currently, if an associative comdat appears after the comdat it's associated
with it's processed immediately, else it's deferred until the end of the object
file. I found this confusing to think about while working on PR40094, so this
makes it so that associated comdats are always processed at the end of the
object file.  This seems to be perf-neutral and simpler.

Now there's a natural place to reject the associated comdats referring to later
associated comdats (associated comdats referring to associated comdats is
invalid per COFF spec) that, so reject those. (A later patch will reject
associated comdats referring to earlier comdats.)

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

llvm-svn: 351917

MemoryBlock: Do not automatically extend a given size to a multiple of page size.

Previously, MemoryBlock automatically extends a requested buffer size to a
multiple of page size because (I believe) doing it was thought to be harmless
and with that you could get more memory (on average 2KiB on 4KiB-page systems)
"for free".

That programming interface turned out to be error-prone. If you request N
bytes, you usually expect that a resulting object returns N for `size()`.
That's not the case for MemoryBlock.

Looks like there is only one place where we take the advantage of
allocating more memory than the requested size. So, with this patch, I
simply removed the automatic size expansion feature from MemoryBlock
and do it on the caller side when needed. MemoryBlock now always
returns a buffer whose size is equal to the requested size.

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

llvm-svn: 351916

[builtins] Do not set hidden attribute on Android

Bionic libc relies on an old libgcc behaviour which does not set hidden
visibility attribute. Keep exporting these symbols on Android for
compatibility.

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

llvm-svn: 351915

[llvm-objcopy] Remove os-dependent message from test

llvm-svn: 351914

[Sema][ObjC] Check whether a DelayedDiagnosticPool has been pushed
before adding a delayed diagnostic to DelayedDiagnostics.

This fixes an assertion failure in Sema::DelayedDiagnostics::add that
was caused by the changes made in r141037.

rdar://problem/42782323

llvm-svn: 351911

[CodeView] Allow empty types in member functions

Summary:
`CodeViewDebug::lowerTypeMemberFunction` used to default to a `Void`
return type if the function's type array was empty. After D54667, it
started blindly indexing the 0th item for the return type, which fails
in `getOperand` for empty arrays if assertions are enabled.

This patch restores the `Void` return type for empty type arrays, and
adds a test generated by Rust in line-only debuginfo mode.

Reviewers: zturner, rnk

Reviewed By: rnk

Subscribers: hiraditya, JDevlieghere, llvm-commits

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

llvm-svn: 351910

[llvm-objcopy] Fix error message for msvc tests

llvm-svn: 351905

Revert "[dotest] Add logging to investigate CI issue."

We figured out the issue so the logging is no longer necessary. It turns
out we were using a session format that was not unique for inline tests.

llvm-svn: 351902

COFF, ELF: ICF: Perform 2 rounds of relocation hash propagation.

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

COFF, ELF: Adjust ICF hash computation to account for self relocations.

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

Fixed isReMaterializable setting for LUI instruction.

llvm-svn: 351895

[HotColdSplit] Calculate BFI lazily to reduce compile-time, NFC

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

[Chrono] Remove ATTRIBUTE_ALWAYS inline from Chrono.h.

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

[HotColdSplit] Calculate domtrees lazily to reduce compile-time, NFC

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

[ADT] Move away from __attribute__((always_inline)).

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

[LegalizeTypes] Add debug prints to the top of PromoteFloatOperand and PromoteFloatResult.

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

[mips] Replace help-text for '-m{no}-relax-pic-calls'. NFC

Thanks to Simon Dardis for the new text.

llvm-svn: 351889

Silence warnings about unused parameters

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

AMDGPU/GlobalISel: Start selectively legalizing 16-bit operations

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

[Docs] Add a note clarifying how to get good test performances.

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

llvm-svn: 351885

AMDGPU/GlobalISel: Handle legality/regbanks for 32/64-bit shifts

llvm-svn: 351884

FileOutputBuffer: handle mmap(2) failure

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

GlobalISel: Allow shift amount to be a different type

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

[FileCheck] Suppress old -v/-vv diags if dumping input

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

GlobalISel: Make buildConstant handle vectors

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

llvm-svn: 351880

[CMake] Fix two details from r351863

llvm-svn: 351879

Remove an unused variable

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

llvm-svn: 351878

Add casts to avoid warnings about implicit conversions losing precision

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

Fix warnings about printf format strings

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

Enable LLVM_ENABLE_WARNINGS when building standalone out of tree

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

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

llvm-svn: 351875

[X86][AVX512F_SCALAR]: Adding full coverage of MC encoding for the AVX512F_SCALAR isa sets. NFC

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

Enable LLVM_ENABLE_WARNINGS when building standalone out of tree

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

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

llvm-svn: 351873

GlobalISel: Implement widen for extract_vector_elt elt type

llvm-svn: 351871

[doc] Replace 'class' with 'struct' for 'public' by default

Make sample syntax correct.

llvm-svn: 351867

GlobalISel: Implement fewerElementsVector for basic FP ops

llvm-svn: 351866

[analyzer] Insert notes in RetainCountChecker where our dynamic cast modeling assumes 'null' output

rdar://47397214

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

llvm-svn: 351865

[analyzer] Model another special-case kind of cast for OSObject RetainCountChecker

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

llvm-svn: 351864

[CMake] Replace use of llvm-config with LLVM and Clang CMake packages

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

[Documentation] Use HTTPS whenever possible.

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

llvm-svn: 351862

Add missing include (cstdlib) to Demangle.h

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

llvm-svn: 351861

AMDGPU/GlobalISel: Remove vectors from legal constant types

llvm-svn: 351859

GlobalISel: Support narrowing zextload/sextload

llvm-svn: 351856

[libFuzzer][MSVC] Enable building libFuzzer with MSVC

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

[SelectionDAGBuilder] Defer C_Register Assignments to be in line with
those of C_RegisterClass. NFCI.

llvm-svn: 351854

GlobalISel: Disallow vectors for G_CONSTANT/G_FCONSTANT

llvm-svn: 351853