| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
This flag was missing but it wasn't an issue as nothing depended on it
for these asm parser-only instructions. Now that LLDB support is slowly
landing, it is important to get this right.
Committing on behalf of Leonardo Bianconi.
Differential revision: https://reviews.llvm.org/D40846
llvm-svn: 320475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The last of the three patches that https://reviews.llvm.org/D40348 was
broken up into.
Canonicalize the materialization of constants so that they are more likely
to be CSE'd regardless of the bit-width of the use. If a constant can be
materialized using PPC::LI, materialize it the same way always.
For example:
li 4, -1
li 4, 255
li 4, 65535
are equivalent if the uses only use the low byte. Canonicalize it to the
first form.
Differential Revision: https://reviews.llvm.org/D40348
llvm-svn: 320473
|
| |
|
|
|
|
|
|
|
|
| |
[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
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 320439
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Original change: https://reviews.llvm.org/D40875
llvm-svn: 320432
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 320424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function stack poisioner conditionally stores local variables
either in an alloca or in malloc'ated memory, which has the
unfortunate side-effect, that the actual address of the variable is
only materialized when the variable is accessed, which means that
those variables are mostly invisible to the debugger even when
compiling without optimizations.
This patch stores the address of the local stack base into an alloca,
which can be referred to by the debug info and is available throughout
the function. This adds one extra pointer-sized alloca to each stack
frame (but mem2reg can optimize it away again when optimizations are
enabled, yielding roughly the same debug info quality as before in
optimized code).
rdar://problem/30433661
Differential Revision: https://reviews.llvm.org/D41034
llvm-svn: 320415
|
| |
|
|
|
|
|
|
|
|
|
| |
The pass to expand ISEL instructions into if-then-else sequences in patch D23630
is currently disabled. This patch partially enable it by always removing the
unnecessary ISELs (all registers used by the ISELs are the same one) and folding
the ISELs which have the same input registers into unconditional copies.
Differential Revision: https://reviews.llvm.org/D40497
llvm-svn: 320414
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r319620, the host build was changed to use Native for
TARGETS_TO_BUILD because passing semicolons through add_custom_command
is surprisingly difficult. However, Native really doesn't make any
sense here, and it only works because we don't technically do any
codegen in the host tools so pretty well anything will "work".
The problem here is that passing something other than the correct
value is very fragile - as evidence note how the llvm-config in the
host tools acts differently than the target one now, and misreports
the targets to build. Similarly, if there is any logic conditional on
the targets in tablegen (now or in the future), it will do the wrong
thing.
To fix this, we need to escape the semicolons in the targets string
and pass it through to the child cmake invocation.
llvm-svn: 320413
|
| |
|
|
|
|
|
|
|
| |
In all cases except for this optimistic attempt to reuse memory, the
moved-from TinyPtrVector was left `empty()` at the end of this
assignment. Though using a container after it's been moved from can be a
bit sketchy, it's probably best to just be consistent here.
llvm-svn: 320408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 320407
|
| |
|
|
| |
llvm-svn: 320404
|
| |
|
|
| |
llvm-svn: 320403
|
| |
|
|
| |
llvm-svn: 320402
|
| |
|
|
| |
llvm-svn: 320400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug where the verifier was complaining about empty
accelerator tables. When the table is empty, its size is not a valid
offset as it points after the end of the section.
This patch also makes the extractor return llvm:Error instead of bool
for better error reporting in the verifier.
Differential revision: https://reviews.llvm.org/D41063
rdar://35932007
llvm-svn: 320399
|
| |
|
|
| |
llvm-svn: 320397
|
| |
|
|
| |
llvm-svn: 320395
|
| |
|
|
| |
llvm-svn: 320392
|
| |
|
|
| |
llvm-svn: 320389
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is due to PR26161 needing to be resolved before we can fix
big endian bugs like PR35359. The work to split aggregates into smaller LLTs
instead of using one large scalar will take some time, so in the mean time
we'll fall back to SDAG.
Some ARM BE tests xfailed for now as a result.
Differential Revision: https://reviews.llvm.org/D40789
llvm-svn: 320388
|
| |
|
|
|
|
| |
Tag LWP instructions as WriteSystem
llvm-svn: 320387
|
| |
|
|
| |
llvm-svn: 320386
|
| |
|
|
| |
llvm-svn: 320385
|
| |
|
|
| |
llvm-svn: 320384
|
| |
|
|
| |
llvm-svn: 320383
|
| |
|
|
| |
llvm-svn: 320382
|
| |
|
|
|
|
|
| |
For some reason the override directives got removed in r320373.
I suspect this to be an unwanted effect of clang-format.
llvm-svn: 320381
|
| |
|
|
| |
llvm-svn: 320380
|
| |
|
|
| |
llvm-svn: 320379
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- 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: 320378
|
| |
|
|
| |
llvm-svn: 320376
|
| |
|
|
|
|
|
|
|
|
|
|
| |
See bugs 35494 and 35559:
https://bugs.llvm.org/show_bug.cgi?id=35494
https://bugs.llvm.org/show_bug.cgi?id=35559
Reviewers: vpykhtin, artem.tamazov, arsenm
Differential Revision: https://reviews.llvm.org/D41007
llvm-svn: 320375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At first, I tried to thread the x86 needle and use a target hook (isVectorShiftByScalarCheap())
to disable the transform only for non-splat pow-of-2 constants, but not AVX2, but only some
element types, but...it's difficult.
Here we just avoid the loop with the x86 vector transform that conflicts with the general DAG
combine and preserve all of the existing behavior AFAICT otherwise.
Some tests that will probably fail if someone does try to restrict this in a more targeted way
for x86-only may be found in:
test/CodeGen/X86/combine-mul.ll
test/CodeGen/X86/vector-mul.ll
test/CodeGen/X86/widen_arith-5.ll
This should prevent the infinite looping seen with:
https://bugs.llvm.org/show_bug.cgi?id=35579
Differential Revision: https://reviews.llvm.org/D41040
llvm-svn: 320374
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces getShadowOriginPtr(), a method that obtains both the shadow and origin pointers for an address as a Value pair.
The existing callers of getShadowPtr() and getOriginPtr() are updated to use getShadowOriginPtr().
The rationale for this change is to simplify KMSAN instrumentation implementation.
In KMSAN origins tracking is always enabled, and there's no direct mapping between the app memory and the shadow/origin pages.
Both the shadow and the origin pointer for a given address are obtained by calling a single runtime hook from the instrumentation,
therefore it's easier to work with those pointers together.
Reviewed at https://reviews.llvm.org/D40835.
llvm-svn: 320373
|