| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
(PR21160, PR34080, PR34454).
Match regular x87 memory fold instructions with load/sideeffects tags, to prevent the schedulers from re-ordering them across the fnstcw/fldcw sequences for truncating stores while they are still pseudo during the stack conversion pass.
llvm-svn: 321424
|
|
|
|
|
|
| |
scheduled differently
llvm-svn: 321423
|
|
|
|
|
|
| |
Did my best to reduce this, but the X87 scheduling bug is hard to hit at the best of times...
llvm-svn: 321422
|
|
|
|
|
|
|
|
|
| |
As for normal task creation, the task frame addresses need to be stored
for the encountering task.
Differential Revision: https://reviews.llvm.org/D41165
llvm-svn: 321421
|
|
|
|
|
|
| |
Previously we extended v2i1 to v2f64 and then tried to use cvtuqq2pd/cvtqq2pd, but that only works with avx512dq. So we ended up scalarizing it. Now we widen to v4i1 first and extend to v4i32.
llvm-svn: 321420
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently llvm-mc ignores COMDATs whose names are numbers,
for example following code:
.section .foo,"G",@progbits,123,comdat
would produce no COMDATs at all.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D41552
llvm-svn: 321419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and data commands.
Advance the memory region offset when handling a linker script data
command such as BYTE or LONG. Failure to advance the offset results
in corrupted output with overlapping sections.
Update tests to check for this combination of both a) memory regions
and b) data commands.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35565
Patch by Owen Shaw!
llvm-svn: 321418
|
|
|
|
|
|
|
|
| |
other combines a chance to run.
This moves the combine for turning ANDs into shuffle with zero out of SimplifyVBinOps and places it only in visitAND below the reassociate handling. This fixes the specific case I noticed where we failed to combine two ands with constants.
llvm-svn: 321417
|
|
|
|
|
|
| |
consistent with the other AVX512 ISAs.
llvm-svn: 321416
|
|
|
|
|
|
| |
RHS not just all zeros/ones.
llvm-svn: 321415
|
|
|
|
|
|
| |
of constant build vectors.
llvm-svn: 321414
|
|
|
|
|
|
|
|
|
|
|
| |
By following the single predecessors of the predecessors of the call
site, we do not need to restrict the control flow.
Reviewed By: junbuml, davide
Differential Revision: https://reviews.llvm.org/D40729
llvm-svn: 321413
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This improves a few things:
- the insert -> freeze -> read sequence is now enforced/communicated by the
type system
- SymbolSlab::const_iterator iterates over symbols, not over id-symbol pairs
- we avoid permanently storing a second copy of the IDs, and the
string map's hashtable
The slab size is now down to 21.8MB for the LLVM project.
Of this only 2.7MB is strings, the rest is #symbols * `sizeof(Symbol)`.
`sizeof(Symbol)` is currently 96, which seems too big - I think
SymbolInfo isn't efficiently packed. That's a topic for another patch!
Also added simple API to see the memory usage/#symbols of a slab, since
it seems likely we will continue to care about this.
Reviewers: ilya-biryukov
Subscribers: klimek, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D41506
llvm-svn: 321412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is currently 16 bytes, the patch reduces it to 4.
(Building with clang on linux x84, I guess others are similar)
The only subfield that might need a bigger type is SymbolPropertySet,
I've moved it to the end of the struct so if it grows, SymbolInfo will
only be 8 bytes.
With a full index of namespace-scope symbols from the LLVM project (200k)
loaded into clangd, this saves ~2MB of RAM.
Reviewers: akyrtzi
Subscribers: ilya-biryukov, cfe-commits
Differential Revision: https://reviews.llvm.org/D41514
llvm-svn: 321411
|
|
|
|
|
|
| |
See https://reviews.llvm.org/rC321409 for additional context.
llvm-svn: 321410
|
|
|
|
|
|
|
|
| |
NamedDecl (vs Decl)
This patch addresses a FIXME and has the template-parameter processing functions return a more derived common type NamedDecl (as opposed to a type needlessly higher up in the inheritance hierarchy : Decl).
llvm-svn: 321409
|
|
|
|
|
|
| |
This can help AVX-512 code where mask types are legal allowing us to remove extends and truncates to/from mask types.
llvm-svn: 321408
|
|
|
|
|
|
|
|
| |
truncate on N1.
Later in the code we explicitly bypass the truncate so we should be checking its type to make sure that it's safe.
llvm-svn: 321407
|
|
|
|
|
|
|
|
| |
Immediately after it is created we check if its equal to another EVT. Then we inconsistently use one or the other variables in the code below.
Instead do the equality check directly on the getValueType result and remove the variable. Use the origina VT variable throughout the remaining code.
llvm-svn: 321406
|
|
|
|
| |
llvm-svn: 321405
|
|
|
|
|
|
|
|
|
|
| |
We normally avoid "switch (Config->EKind)", but in this case I think
it is worth it.
It is only executed when there is an error and it allows detemplating
a lot of code.
llvm-svn: 321404
|
|
|
|
| |
llvm-svn: 321403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code was originally removed and replace with an assertion
because believed unnecessary. It turns out there was simply
no test coverage for this case, and the constant folder doesn't
yet know about patterns like `br undef %label1, %label2`.
Presumably at some point the constant folder might learn about
these patterns, but it's a broader change.
A testcase will be added to make sure this doesn't regress again
in the future.
Fixes PR35723.
llvm-svn: 321402
|
|
|
|
|
|
| |
This will be used to help tidyup existing pseudos that we've added scheduling info to.
llvm-svn: 321401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of PR35720.
Currently LLD allows dynamic relocations against text when -z notext is given.
Though for non-PIC relocations like R_X86_64_PC32 that does not work,
we produce "relocation R_X86_64_PC32 cannot be used against shared object;"
error because they may overflow in runtime.
Solution implemented is to use PLT for them.
Differential revision: https://reviews.llvm.org/D41541
llvm-svn: 321400
|
|
|
|
|
|
| |
Apparently we don't have tests for this which I didn't realize before. I'll try to fix that but wanted to fix the obvious bug.
llvm-svn: 321399
|
|
|
|
| |
llvm-svn: 321398
|
|
|
|
|
|
|
|
|
|
| |
to get the type of the operand.
getOperand returns an SDValue that contains the node and the result number. There is no guarantee that the result number if 0. By using the -> operator we are calling SDNode::getValueType rather than SDValue::getValueType. This requires supplying a result number and we shouldn't assume it was 0.
I don't have a test case. Just noticed while cleaning up some other code and saw that it occurred in other places.
llvm-svn: 321397
|
|
|
|
|
|
|
| |
Turn off hashing for class methods, but leave it on for other functions. This
should get the buildbot to green for the time being.
llvm-svn: 321396
|
|
|
|
|
|
|
| |
Extend the hashing to functions, which allows detection of function definition
mismatches across modules. This is a re-commit of r320230.
llvm-svn: 321395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Export aligned new/delete to make dynamic runtimes work again.
Remove all valid new/delete cases from ASan test, there's a test in
common for that.
Reviewers: eugenis
Subscribers: srhines, kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41548
llvm-svn: 321394
|
|
|
|
| |
llvm-svn: 321393
|
|
|
|
|
|
| |
fallthrough. Fixes GCC and Clang warnings about this.
llvm-svn: 321392
|
|
|
|
| |
llvm-svn: 321391
|
|
|
|
|
|
|
|
|
|
| |
When two linker script symbols are subtracted, the result should be absolute.
This is the behavior of binutils' ld.
Patch by Erick Reyes!
llvm-svn: 321390
|
|
|
|
|
|
|
|
|
| |
BaseIndexOffset supercedes findBaseOffset analysis save only Constant
Pool addresses. Migrate analysis to BaseIndexOffset.
Relanding after correcting base address matching check.
llvm-svn: 321389
|
|
|
|
|
|
|
|
|
|
| |
Summary: Correctly handle files ignored by svn (such as .o files,
which are ignored by default) by adding "--no-ignore" flag to "svn
status" and "svn add".
Differential Revision: https://reviews.llvm.org/D41404
llvm-svn: 321388
|
|
|
|
| |
llvm-svn: 321387
|
|
|
|
|
|
|
|
| |
If the clause is applied to the combined construct and has captured
expression, try to capture this expression by value rather than by
reference.
llvm-svn: 321386
|
|
|
|
|
|
|
|
| |
LLVM-side is now fixed
Differential Revision: https://reviews.llvm.org/D41511
llvm-svn: 321385
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, taking the address for an alias would result in:
"Symbol not found in table index space"
Increase test coverage for weak aliases.
This code should be more efficient too as it avoids building
the `IsAddressTaken` set.
Differential Revision: https://reviews.llvm.org/D41510
llvm-svn: 321384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r318733 introduced a build failure for native MIPS32 systems for xray due
to the lack of __sync_fetch_and_add / __syn_fetch_and_sub support. This patch
extends the existing support providing atomics so that xray can be
successfully built.
The initial patch was reverted in r321292, as I suspected it may have caused the
buildbot failure. Another patch in the updates the bot fetched caused the test
failures which was reverted.
Reviewers: atanasyan, dberris
Differential Revision: https://reviews.llvm.org/D40385
llvm-svn: 321383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loads.
Summary:
Make MemorySSA allow reordering of two loads that may alias, when one is volatile.
This makes MemorySSA less conservative and behaving the same as the AliasSetTracker.
For more context, see D16875.
LLVM language reference: "The optimizers must not change the number of volatile operations or change their order of execution relative to other volatile operations. The optimizers may change the order of volatile operations relative to non-volatile operations. This is not Java’s “volatile” and has no cross-thread synchronization behavior."
Reviewers: george.burgess.iv, dberlin
Subscribers: sanjoy, reames, hfinkel, llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D41525
llvm-svn: 321382
|
|
|
|
|
|
|
| |
The difference is the avoidance of a few absolute paths. Thanks to
Galina Kistanova for the patch.
llvm-svn: 321381
|
|
|
|
|
|
|
|
|
|
| |
NFCI."
which was causing miscompilations in for some test-suite components.
This reverts commit 3e9de9ff0f3162920a2a3cba51c7dc14b54b4d16.
llvm-svn: 321380
|
|
|
|
|
|
|
|
| |
Without this initialization this test case tend to fail.
Differential Revision: https://reviews.llvm.org/D41542
llvm-svn: 321379
|
|
|
|
|
|
| |
Fixing parameters in clang-tidy fuchsia-overloaded-operator test case
llvm-svn: 321378
|
|
|
|
|
|
|
|
|
|
| |
If after if-conversion, most of the instructions in this new BB construct a long and slow dependence chain, it may be slower than cmp/branch, even if the branch has a high miss rate, because the control dependence is transformed into data dependence, and control dependence can be speculated, and thus, the second part can execute in parallel with the first part on modern OOO processor.
This patch checks for the long dependence chain, and give up if-conversion if find one.
Differential Revision: https://reviews.llvm.org/D39352
llvm-svn: 321377
|
|
|
|
|
|
|
|
|
|
|
| |
In https://reviews.llvm.org/rL321077 and https://reviews.llvm.org/D41231 I fixed a regression in the c-api which prevented the pruning from being *effectively* disabled.
However this approach, helpfully recommended by @labath, is cleaner.
It is also nice to remove the weasel words about effectively disabling from the api comments.
Differential Revision: https://reviews.llvm.org/D41497
llvm-svn: 321376
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-land r321234. It had to be reverted because it broke the shared
library build. The shared library build broke because there was a
missing LLVMBuild dependency from lib/Passes (which calls
TargetMachine::getTargetIRAnalysis) to lib/Target. As far as I can
tell, this problem was always there but was somehow masked
before (perhaps because TargetMachine::getTargetIRAnalysis was a
virtual function).
Original commit message:
This makes the TargetMachine interface a bit simpler. We still need
the std::function in TargetIRAnalysis to avoid having to add a
dependency from Analysis to Target.
See discussion:
http://lists.llvm.org/pipermail/llvm-dev/2017-December/119749.html
I avoided adding all of the backend owners to this review since the
change is simple, but let me know if you feel differently about this.
Reviewers: echristo, MatzeB, hfinkel
Reviewed By: hfinkel
Subscribers: jholewinski, jfb, arsenm, dschuff, mcrosier, sdardis, nemanjai, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D41464
llvm-svn: 321375
|