Summary:
This solves PR35616.

We don't want the compiler to generate different code when we compile
with/without -g, so we now ignore debug intrinsics when determining if
the optimization can trigger or not.

Reviewers: junbuml

Subscribers: davide, JDevlieghere, llvm-commits

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

llvm-svn: 320460

llvm-svn: 320459

llvm-svn: 320458

[AMDGPU] Rename Bonaire target to be gfx704; remove gfx800 and make Iceland and Tonga both use gfx802; update target feature handling

Correct committed version to match intended accepted review D40051 id=123417

- Rename Bonaire target to be gfx704.
- Eliminate gfx800 and make Iceland and Tonga both use gfx802 as they use the same code.
- List target features supported by each processor in the processor table together with the default value.
- Add xnack flag to e_flags.
- Remove xnack from kernel metadata and kernel descriptor since it is now a whole code object property.

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

llvm-svn: 320457

This unbreaks the lldb modules build (-DLLVM_ENABLE_MODULES=On).

llvm-svn: 320456

The new check introduced in r318705 is useful, but suffers from a particular
class of false positives, namely, it does not account for
dispatch_barrier_sync() API which allows one to ensure that the asyncronously
executed block that captures a pointer to a local variable does not actually
outlive that variable.

The new check is split into a separate checker, under the name of
alpha.core.StackAddressAsyncEscape, which is likely to get enabled by default
again once these positives are fixed. The rest of the StackAddressEscapeChecker
is still enabled by default.

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

llvm-svn: 320455

Remove yet another spurious unexpected success.
Ack'ed by Jim Ingham.

Fixes PR25743.

llvm-svn: 320454

I tested on x86-64 and Jason on embedded architectures.
This cleans up another couple of reported unexpected successes.

<rdar://problem/28623427>

llvm-svn: 320452

This is a follow-up from r314910. When a checker developer attempts to
dereference a location in memory through ProgramState::getSVal(Loc) or
ProgramState::getSVal(const MemRegion *), without specifying the second
optional QualType parameter for the type of the value he tries to find at this
location, the type is auto-detected from location type. If the location
represents a value beyond a void pointer, we thought that auto-detecting the
type as 'char' is a good idea. However, in most practical cases, the correct
behavior would be to specify the type explicitly, as it is available from other
sources, and the few cases where we actually need to take a 'char' are
workarounds rather than an intended behavior. Therefore, try to fail with an
easy-to-understand assertion when asked to read from a void pointer location.

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

llvm-svn: 320451

With this one, the number of unexpected successes for the LLDB
test suite when building with clang ToT goes down to 18.

llvm-svn: 320450

By using an index instead of a pointer for verdef we can put the index
next to the alignment field. This uses the otherwise wasted area and
reduces the shared symbol size.

By itself the performance change of this is in the noise, but I have a
followup patch to remove another 8 bytes that improves performance
when combined with this.

llvm-svn: 320449

An internal linker has support for merging identical data and in some
cases it can be a significant win.

This is behind an off by default flag so it has to be requested
explicitly.

llvm-svn: 320448

After discussing this with Jim and Jason, I think my commit was
actually sweeping the issue under the carpet rather than fixing it.
I'll take a closer look between tonight and tomorrow.

llvm-svn: 320447

This also slightly refactors the code that's checking the directory
presence which allows eliminating one unnecessary variable.

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

llvm-svn: 320446

These are expected to be set by the shared lit scripts used from libc++.

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

llvm-svn: 320445

Some tests are failing on macOS when building with the in-tree
clang, and this is because they're conditional on the version released.
Apple releases using a different versioning number, but as these are
conditional on clang < 7, they fail for clang ToT (which is 6.0).
As a general solution, we actually need either a mapping between
Apple internal release version and public ones.

That said, I discussed this with Fred , and Apple Clang 6.0 seems
to be old enough that we can remove this altogether (which means I
can delay implementing the general purpose solution for a bit).

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

llvm-svn: 320444

This adds the install-*-stripped targets to LLDB, which are required for
the install-distribution-stripped option. We also need to create some
install-*-stripped targets manually, which are modeled after their
corresponding install-* targets.

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

llvm-svn: 320443

This is less error-prone to mask settings than stat.

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

llvm-svn: 320442

Also make function bodies unique so they can be distinguished
in the output.  This is helpful for adding support for --gc-sections.

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

llvm-svn: 320441

llvm-svn: 320439

These are not executable files so they shouldn't be marked as such.

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

llvm-svn: 320438

When an output section has no byte commands and has no input sections then it
would be ideal if the type of the section is SHT_NOBITS so that the file can
take up less space. This change sets the default type of of output sections to
SHT_NOBITS instead of SHT_PROGBITS to allow this. This required some minor test
changes (which double as tests for this new behavior) but extend-pt-load.s had
be changed in a non-trivial way. Since it seems to me that the point of the
test is to point out the consequences of how flags are assigned to output
sections that don't have input sections I changed the test to work and still
show how the memsize of the executable segment was changed.

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

llvm-svn: 320437

llvm-svn: 320436

Summary:
That allows to get the same data as produced by "llvm-cov report",
but in JSON format, which is better for further processing by end users.

Reviewers: vsk

Reviewed By: vsk

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

llvm-svn: 320435

In the following command line,

  lld-link foo/bar.lib /defaultlib:bar.lib

"/defaultlib:bar.lib" should be a nop even if a file with the same
name exists in other library search path.

Fixes https://bugs.llvm.org/show_bug.cgi?id=35476

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

llvm-svn: 320434

llvm-svn: 320433

Original change: https://reviews.llvm.org/D40875

llvm-svn: 320432

This fixes an assertion error introduced by r320390.

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

llvm-svn: 320431

The PPC port doesn't support PLT yet, but the architecture independent
code optimizes PLT access for non preemptible symbols, which is
exactly what returning R_PC was trying to implement.

llvm-svn: 320430

See bug https://bugs.llvm.org/show_bug.cgi?id=35631
r318704 is giving a fatal error on some code with unsigned to floating point
conversions.

llvm-svn: 320429

Create the indirect function table based on symbols rather
than just duplicating the input entries.  This has the
effect of de-duplicating the table.

This is a followup to the equivalent change made for globals:
  https://reviews.llvm.org/D40859

Partially based on a patch by Nicholas Wilson:
  https://reviews.llvm.org/D40845

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

llvm-svn: 320428

log are also diagnostics so it seems like they should to
the same place as errors and debug messages.

Without this change when I enable --verbose those messages
go to stdout, but when I enable "-mllvm -debug" those messages
go to stderr (because dbgs() goes to stderr by default).

So I end up having to do this a lot:
 lld <args> > output_message 2>&1

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

llvm-svn: 320427

This change restores the behavior that global indexes
are assigned in object file order.  This was accidentally
changed in https://reviews.llvm.org/D40859.

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

llvm-svn: 320426

This is the first of a series of commits aiming to improve
overall LLDB's hygiene. Feel free to shout at me in case
I break something.

<rdar://problem/30915340>

llvm-svn: 320425

llvm-svn: 320424

llvm-svn: 320423

Should hopefully bring the bots back.

<rdar://problem/35976115>

llvm-svn: 320422

The tests fail (opt asserts) on Windows.

> Summary:
> If we have pattern `store (load(bitcast(select (cmp(V1, V2), &V1,
> &V2)))), bitcast)`, but the load is used in other instructions, it leads
> to looping in InstCombiner. Patch adds additional check that all users
> of the load instructions are stores and then replaces all uses of load
> instruction by the new one with new type.
>
> Reviewers: RKSimon, spatel, majnemer
>
> Subscribers: llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D41072

llvm-svn: 320421

When either instruction in a fused pair has no other dependency, besides on
the other instruction, make sure that other instructions do not get
scheduled between them.  Additionally, avoid fusing an instruction more than
once along the same dependency chain.

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

llvm-svn: 320420

This adds a new command line option -mprefer-vector-width to specify a preferred vector width for the vectorizers. Valid values are 'none' and unsigned integers. The driver will check that it meets those constraints. Specific supported integers will be managed by the targets in the backend.

Clang will take the value and add it as a new function attribute during CodeGen.

This represents the alternate direction proposed by Sanjay in this RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-November/118734.html

The syntax here matches gcc, though gcc treats it as an x86 specific command line argument. gcc only allows values of 128, 256, and 512. I'm not having clang check any values.

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

llvm-svn: 320419