| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
[X86] Use regular expressions more aggressively to reduce the number of scheduler entries needed for FMA3 instructions.
When the scheduler tables are generated by tablegen, the instructions are divided up into groups based on their default scheduling information and how they are referenced by groups for each processor. For any set of instructions that are matched by a specific InstRW line, that group of instructions is guaranteed to not be in a group with any other instructions. So in general, the more InstRW class definitions are created, the more groups we end up with in the generated files. Particularly if a lot of the InstRW lines only match to single instructions, which is true of a large number of the Intel scheduler models.
This change alone reduces the number of instructions groups from ~6000 to ~5500. And there's lots more we could do.
llvm-svn: 320470
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch removes the hard-coded check for DWARFv2 line tables. Now
dsymutil accepts line tables for DWARF versions 2 to 5 (inclusive).
Differential revision: https://reviews.llvm.org/D41084
rdar://35968319
llvm-svn: 320469
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It will be used to pass around things like Logger and Tracer throughout
clangd classes.
Reviewers: sammccall, ioeric, hokein, bkramer
Reviewed By: sammccall
Subscribers: klimek, bkramer, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40485
llvm-svn: 320468
|
| |
|
|
| |
llvm-svn: 320467
|
| |
|
|
|
|
|
| |
They were causing failures of the piglit OpenGL tests with AMD GPUs using the
Mesa radeonsi driver.
llvm-svn: 320466
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Introduces usage of AvailableValueSet alias name instead of
DenseSet<const Value *> for better reading.
Patch Author: Daniil Suchkov
Reviewers: mkazantsev, anna, apilipenko
Reviewed By: anna
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41002
llvm-svn: 320465
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D40970
llvm-svn: 320464
|
| |
|
|
|
|
|
|
|
| |
VecValuesToIgnore holds values that will not appear in the vectorized loop.
We should therefore ignore their cost when VF > 1.
Differential Revision: https://reviews.llvm.org/D40883
llvm-svn: 320463
|
| |
|
|
|
|
|
|
| |
This is required for linking the CRT from MSVC 2017 15.5.
Differential Revision: https://reviews.llvm.org/D41089
llvm-svn: 320462
|
| |
|
|
|
|
|
|
|
|
| |
scheduler entries needed for FMA3 instructions.
When the scheduler tables are generated by tablegen, the instructions are divided up into groups based on their default scheduling information and how they are referenced by groups for each processor. For any set of instructions that are matched by a specific InstRW line, that group of instructions is guaranteed to not be in a group with any other instructions. So in general, the more InstRW class definitions are created, the more groups we end up with in the generated files. Particularly if a lot of the InstRW lines only match to single instructions, which is true of a large number of the Intel scheduler models.
This change alone reduces the number of instructions groups from ~6000 to ~5500. And there's lots more we could do.
llvm-svn: 320461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
minmax load bitcast."
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
during CodeGen.
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
|