Previously we used precompiled objects in gdb-index.s and
debug-gnu-pubnames.s testcases. We can avoid that.

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

llvm-svn: 308005

Constants are crucial for code size in the ARM Thumb-1 instruction
set. The 16 bit instruction size often does not offer enough space
for immediate arguments. This means that additional instructions are
frequently used to load constants into registers. Since constants are
hoisted, this can lead to significant register spillage if they are
used multiple times in a single function. This can be avoided by
rematerialization, i.e. recomputing a constant instead of reloading
it from the stack. This patch fixes the rematerialization of literal
pool loads in the ARM Thumb instruction set.

Patch by Philip Ginsbach

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

llvm-svn: 308004

In filling the .got sections, InputSection::OutSecOff was added twice
when finding the position to apply a relocation: first time in
InputSection::writeTo() and then in SectionBase::getOffset().

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

llvm-svn: 308003

This probably doesn't change anything because the frotend doesn't do anything with this feature and the backend will infer from the cpu string. So this is just for consistency with other cpus that support movbe.

llvm-svn: 308002

When iterating through loop

  for (int i = INT_MAX; i > 0; i--)

We fail to generate the pre-loop for it. It happens because we use the
overflown value in a comparison predicate when identifying whether or not
we need it.

In old logic, we used SLE predicate against Greatest value which exceeds all
seen values of the IV and might be overflown. Now we use the GreatestSeen
value of this IV with SLT predicate.

Also added a test that ensures that a pre-loop is generated for such loops.

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

llvm-svn: 308001

Without this, there was no progress shown during parsing but only during
rendering on macOS.

llvm-svn: 308000

llvm-svn: 307999

The /appcontainer flag was added in r299728, and the lib.exe dependency
for creating import libraries was removed in r275242. Update the docs
accordingly.

The PDB support also needs updating, but I'll leave that for someone
who's more familiar with the current status (probably rnk).

llvm-svn: 307998

Once upon a time, extern templates used to be a Microsoft extension, so
cl would warn about their usage, and libc++ suppressed that warning.
They've long since been standardized, so the warning is defunct. (libc++
also doesn't currently support building with cl anyway.)

llvm-svn: 307997

llvm-svn: 307996

llvm-svn: 307995

Use EXPECT_TRUE rather than EXPECT_EQ(true, ...) to clean up the code and silence a null conversion warning.

llvm-svn: 307989

llvm-svn: 307988

llvm-svn: 307987

FunctionDecl already hashes most of the information in the function's type.
Add hashing of the return type, and skip hashing the function's type to avoid
redundancy and extra work when computing the hash.

llvm-svn: 307986

Summary:
This makes sure the correct lib path is being used when `CMAKE_CFG_INTDIR` or
`LLVM_LIBDIR_SUFFIX` is set.

Reviewers: beanz

Subscribers: mgorny, srhines, pirama, llvm-commits

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

llvm-svn: 307985

This was previously erroring out if one of the dead symbols was a
TLS symbol and we were able to discard all TLS sections.

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

llvm-svn: 307984

PT_TLS is a type of program header, so we wouldn't expect to see
one in an object file. This error should probably be referring to
the fact that we didn't see a section with the flag SHF_TLS, which
would normally cause us to create a PT_TLS program header.

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

llvm-svn: 307983

platforms.

Set the target OS based on -target if it is present on the command
line and -arch is not.

With this commit, "-target x86_64-apple-ios8.0" does the same thing as
"-arch x86_64 -mios-version-min=8.0".

rdar://problem/21012522

llvm-svn: 307982

llvm-svn: 307981

llvm-svn: 307980

Summary:
We've accumulated about five or so data structures that are widely
referenced:
- PDBBuilder
- Type table
- Id table
- PDB string table
- Type server handler

I'm about to rewrite type server handling, and I need a new class in LLD
where I can put its state. By creating a new PDBLinker class, I hope to
put it there next.

Reviewers: ruiu

Subscribers: llvm-commits

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

llvm-svn: 307979

This is necessary to pass the kernarg segment pointer
to callee functions. Also don't unconditionally enable
for kernels.

llvm-svn: 307978

llvm-svn: 307977

Since GFX9 supports denorm modes for v_min_f32/v_max_f32 that
is possible to further optimize fcanonicalize and remove it
if applied to min/max given their operands are known not to be
an sNaN or that sNaNs are not supported.

Additionally we can remove fcanonicalize if denorms are supported
for the VT and we know that its argument is never a NaN.

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

llvm-svn: 307976

This patch adds verification checks for the unit header chain in the .debug_info section.
Specifically, for each unit in the .debug_info section, the verifier checks that:

The unit length is valid (i.e. the unit can actually fit in the .debug_info section)
The dwarf version of the unit is valid
The address size is valid (4 or 8)
The unit type (if the unit is in dwarf5) is valid
The debug_abbrev_offset is valid

llvm-svn: 307975

This fixes warnings on some buildbots.

llvm-svn: 307974

llvm-svn: 307973

llvm-svn: 307972

llvm-svn: 307971

Binary streams are an abstraction over a discontiguous buffer. To write
a discontiguous buffer, we want to copy each contiguous chunk
individually. Currently BinaryStreams do not expose a way to iterate
over the chunks, so the code repeatedly calls
readLongestContiguousChunk() with an increasing offset. In order to
lookup the chunk by offset, we would iterate the items list to figure
out which chunk the offset is within. This is obviously O(n^2).

Instead, pre-compute a table of offsets and do a binary search to figure
out which chunk to use. This is still only an O(n^2) to O(n log n)
improvement, but it's a very local fix that seems worth doing.

This improves self-linking lld.exe with PDBs from 90s to 10s.

llvm-svn: 307970

Summary:
libsanitizer doesn't build against latest glibc anymore, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066 for details.
One of the changes is that stack_t changed from typedef struct sigaltstack { ... } stack_t; to typedef struct { ... } stack_t; for conformance reasons.
And the other change is that the glibc internal __need_res_state macro is now ignored, so when doing
```
#define __need_res_state
#include <resolv.h>
```
the effect is now the same as just
```
#include <resolv.h>
```
and thus one doesn't get just the
```
struct __res_state { ... };
```
definition, but newly also the
```
extern struct __res_state *__res_state(void) __attribute__ ((__const__));
```
prototype.  So __res_state is no longer a type, but a function.

Reviewers: kcc, ygribov

Reviewed By: kcc

Subscribers: kubamracek

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

llvm-svn: 307969

Update.Arc of type Arc caused a warning on some buildbots.

llvm-svn: 307968

Previously this wouldn't detect used features indirectly
used in callee functions.

llvm-svn: 307967

It has an extern template instantiation declaration in the headers and a
corresponding instantiation definition in the library, so we must mark
it with _LIBCPP_FUNC_VIS to make it available outside the library.

This doesn't cause any ABI changes as-is since we don't build libc++
with hidden visibility (so the function is exported anyway). It's needed
for building libc++ with hidden visibility, however.

Clarify the Windows behavior for extern function templates while I'm
here, since this exercises that behavior.

llvm-svn: 307966

This has been unused since r282644.

llvm-svn: 307965

llvm-svn: 307964

Summary:
This patch introduces a new testing utility for building and modifying CFG -- CFGBuilder. The primary use case for the utility is testing the upcoming incremental dominator tree update API.

The current design provides a simple mechanism of constructing arbitrary graphs and then applying series of updates to them. CFGBuilder takes care of creating empty functions, connecting and disconnecting basic blocks. Under the hood it uses SwitchInst and UnreachableInst.

It will be also possible to create a thin wrapper over CFGBuilder for parsing string input and to hook it up to other textual tools (e.g. opt used with FileCheck).

Reviewers: dberlin, sanjoy, grosser, dblaikie

Reviewed By: dblaikie

Subscribers: davide, mgorny, llvm-commits

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

llvm-svn: 307960

overrides:  getName can fail if the decl's name isn't a simple identifier.

This is a more general replacement for the fix in r305860.

llvm-svn: 307959

Summary:
Secondary backed allocations do not require a cache. While it's not necessary
an issue when each thread has its cache, it becomes one with a shared pool of
caches (Android), as a Secondary backed allocation or deallocation holds a
cache that could be useful to another thread doing a Primary backed allocation.

We introduce an additional PRNG and its mutex (to avoid contention with the
Fallback one for Primary allocations) that will provide the `Salt` needed for
Secondary backed allocations.

I changed some of the code in a way that feels more readable to me (eg: using
some values directly rather than going  through ternary assigned variables,
using directly `true`/`false` rather than `FromPrimary`). I will let reviewers
decide if it actually is.

An additional change is to mark `CheckForCallocOverflow` as `UNLIKELY`.

Reviewers: alekseyshl

Reviewed By: alekseyshl

Subscribers: llvm-commits

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

llvm-svn: 307958