| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with unreachable default"
This reverts commit 2a0f2c5ef3330846149598220467d9f3c6e8b99c (r355490).
The commit causes an assertion failure when compiling LLVM code:
$ cat repro.cpp
class QQQ {
public:
bool x() const;
bool y() const;
unsigned getSizeInBits() const {
if (y() || x())
return getScalarSizeInBits();
return getScalarSizeInBits() * 2;
}
unsigned getScalarSizeInBits() const;
};
int f(const QQQ &Ty) {
switch (Ty.getSizeInBits()) {
case 1:
case 8:
return 0;
case 16:
return 1;
case 32:
return 2;
case 64:
return 3;
default:
__builtin_unreachable();
}
}
$ clang -O2 -o repro.o repro.cpp
assert.h assertion failed at llvm/include/llvm/ADT/ilist_iterator.h:139 in llvm::ilist_iterator::reference llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::MachineInstr, true, true, void>, true, false>::operator*() const [OptionsT = llvm::ilist_detail::node_options<llvm::MachineInstr, true, true, void>, IsReverse = true, IsConst = false]: !NodePtr->isKnownSentinel()
*** Check failure stack trace: ***
@ 0x558aab4afc10 __assert_fail
@ 0x558aa885479b llvm::ilist_iterator<>::operator*()
@ 0x558aa8854715 llvm::MachineInstrBundleIterator<>::operator*()
@ 0x558aa92c33c3 llvm::X86InstrInfo::optimizeCompareInstr()
@ 0x558aa9a9c251 (anonymous namespace)::PeepholeOptimizer::optimizeCmpInstr()
@ 0x558aa9a9b371 (anonymous namespace)::PeepholeOptimizer::runOnMachineFunction()
@ 0x558aa99a4fc8 llvm::MachineFunctionPass::runOnFunction()
@ 0x558aab019fc4 llvm::FPPassManager::runOnFunction()
@ 0x558aab01a3a5 llvm::FPPassManager::runOnModule()
@ 0x558aab01aa9b (anonymous namespace)::MPPassManager::runOnModule()
@ 0x558aab01a635 llvm::legacy::PassManagerImpl::run()
@ 0x558aab01afe1 llvm::legacy::PassManager::run()
@ 0x558aa5914769 (anonymous namespace)::EmitAssemblyHelper::EmitAssembly()
@ 0x558aa5910f44 clang::EmitBackendOutput()
@ 0x558aa5906135 clang::BackendConsumer::HandleTranslationUnit()
@ 0x558aa6d165ad clang::ParseAST()
@ 0x558aa6a94e22 clang::ASTFrontendAction::ExecuteAction()
@ 0x558aa590255d clang::CodeGenAction::ExecuteAction()
@ 0x558aa6a94840 clang::FrontendAction::Execute()
@ 0x558aa6a38cca clang::CompilerInstance::ExecuteAction()
@ 0x558aa4e2294b clang::ExecuteCompilerInvocation()
@ 0x558aa4df6200 cc1_main()
@ 0x558aa4e1b37f ExecuteCC1Tool()
@ 0x558aa4e1a725 main
@ 0x7ff20d56abbd __libc_start_main
@ 0x558aa4df51c9 _start
llvm-svn: 355515
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows us to store more info about where we're emitting the remarks
without cluttering LLVMContext. This is needed for future support for
the remark section.
Differential Revision: https://reviews.llvm.org/D58996
Original llvm-svn: 355507
llvm-svn: 355514
|
| |
|
|
|
|
|
|
| |
This patch supports secure plt mode for TLS symbols.
Differential Revision: https://reviews.llvm.org/D45520
llvm-svn: 355513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In r354298 a DominatorTree construction was added via new function
combineToUSubWithOverflow, which was subsequently restructured into
replaceMathCmpWithIntrinsic in r354689. We are hitting a very long
compile time due to this repeated construction, once per math cmp in
the function.
We shouldn't need to build the DominatorTree more than once per
function, except when a transformation invalidates it. There is already
a boolean flag that is returned from these methods indicating whether
the DT has been modified. We can simply build the DT once per
Function walk in CodeGenPrepare::runOnFunction, since any time a change
is made we break out of the Function walk and restart it.
I modified the code so that both replaceMathCmpWithIntrinsic as well as
mergeSExts (which was also building a DT) use the DT constructed by the
run method.
From -mllvm -time-passes:
Before this patch: CodeGen Prepare user time is 328s
With this patch: CodeGen Prepare user time is 21s
Reviewers: spatel
Subscribers: jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58995
llvm-svn: 355512
|
| |
|
|
|
|
|
|
| |
This reverts commit 2e8c4997a2089f8228c843fd81b148d903472e02.
Breaks bots.
llvm-svn: 355511
|
| |
|
|
| |
llvm-svn: 355508
|
| |
|
|
|
|
|
|
|
|
| |
This allows us to store more info about where we're emitting the remarks
without cluttering LLVMContext. This is needed for future support for
the remark section.
Differential Revision: https://reviews.llvm.org/D58996
llvm-svn: 355507
|
| |
|
|
|
|
|
|
| |
Basic constant handling folds, for both scalars and vectors
Differential Revision: https://reviews.llvm.org/D58967
llvm-svn: 355506
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D58968
llvm-svn: 355495
|
| |
|
|
|
|
|
|
|
|
| |
As noticed on D58965
DAGCombiner::visitSELECT has something similar, so we should be able to move this to DAGCombiner and support VSELECT as well at some point.
Differential Revision: https://reviews.llvm.org/D58974
llvm-svn: 355494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unreachable default
During the lowering of a switch that would result in the generation of a
jump table, a range check is performed before indexing into the jump
table, for the switch value being outside the jump table range and a
conditional branch is inserted to jump to the default block. In case the
default block is unreachable, this conditional jump can be omitted. This
patch implements omitting this conditional branch for unreachable
defaults.
Differential Revision: https://reviews.llvm.org/D52002
Reviewers: Hans Wennborg, Eli Freidman, Roman Lebedev
llvm-svn: 355490
|
| |
|
|
|
|
| |
newly added test.
llvm-svn: 355487
|
| |
|
|
|
|
|
|
|
|
| |
X86ISD::ADD when the carry flag isn't used.
This allows us to use an 8-bit sign extended immediate instead of a 16 or 32 bit immediate.
Also do similar for 0x80000000 with 64-bit adds to avoid having to use a movabsq.
llvm-svn: 355485
|
| |
|
|
|
|
| |
128 won't fit in a sign extended 8-bit immediate, but we can negate it to -128 and use the other operation. This results in a shorter encoding since the move would have used 16 or 32 bits for the immediate.
llvm-svn: 355484
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unreachable default
During the lowering of a switch that would result in the generation of a
jump table, a range check is performed before indexing into the jump
table, for the switch value being outside the jump table range and a
conditional branch is inserted to jump to the default block. In case the
default block is unreachable, this conditional jump can be omitted. This
patch implements omitting this conditional branch for unreachable
defaults.
Differential Revision: https://reviews.llvm.org/D52002
Reviewers: Hans Wennborg, Eli Freidman, Roman Lebedev
llvm-svn: 355483
|
| |
|
|
|
|
|
|
| |
help printer adds a period.
Most features don't have periods already, but some did. When there is a period it causes llc -mattr=+help to print 2 periods.
llvm-svn: 355474
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58955
llvm-svn: 355472
|
| |
|
|
|
|
| |
for buildbot failures.
llvm-svn: 355461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uses the infrastructure added in rL353152 to sink zext and sexts to
sub/add users, to enable vsubl/vaddl generation when NEON is available.
See https://bugs.llvm.org/show_bug.cgi?id=40025.
Reviewers: SjoerdMeijer, t.p.northover, samparker, efriedma
Reviewed By: samparker
Differential Revision: https://reviews.llvm.org/D58063
llvm-svn: 355460
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When dumping ToT clan's debug info with dwarfdump, we were seeing an
error saying that that the location list overflows the debug_loc
section. After reducing the testcase we figured out that we were
interpreting the DW_FORM_data4 as a section offset.
In DWARF3 DW_FORM_data4 and DW_FORM_data8 served also as a section
offset. Until now we didn't check check for the DWARF version, because
some producers (read old versions of clang) were still emitting this.
The relevant code/comment was added in 2013, and I believe it's now
reasonable to start checking the version.
The FormValue class is a little bit of a mess because it cashes the
DWARF unit and context when it extracted the value itself. Several
methods of the class rely on it being present, or return an Optional for
the code path that needs it. At the same time the FormValue class also
used in places where there's no DWARF unit.
For this patch I went with the least invasive change: checking the
version from the CU when it's available. If it's not (because the form
value was created from a value directly) we default to the old behavior.
Differential revision: https://reviews.llvm.org/D58698
llvm-svn: 355456
|
| |
|
|
|
|
|
|
| |
Be consistent about how we treat atomics in non-zero address spaces. If we get to the backend, we tend to lower them as if in address space 0. Do the same if we need to insert a libcall instead.
Differential Revision: https://reviews.llvm.org/D58760
llvm-svn: 355453
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Replaces some uses of `MachineFunction::iterator(MBB)` with
`MBB->getIterator()` and `MachineBasicBlock::iterator(MI)` with
`MI->getIterator()`, which are simpler.
- Replaces some uses of `std::prev` of `std::next` that takes a
MachineFunction or MachineBasicBlock iterator with `getPrevNode` and
`getNextNode`, which are also simpler.
Reviewers: sbc100
Subscribers: dschuff, sunfish, jgravelle-google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58913
llvm-svn: 355444
|
| |
|
|
|
|
| |
Rename it to reflect that it's parsing YAML remarks.
llvm-svn: 355441
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Getting rid of the name "optimization remarks" for anything that
involves handling remarks on the client side.
It's safer to do this now, before we get stuck with that name in all the
APIs and public interfaces we decide to export to users in the future.
This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now
generates `libRemarks.dylib` instead of `libOptRemarks.dylib`.
Differential Revision: https://reviews.llvm.org/D58535
llvm-svn: 355439
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This pass hurts code size for wasm and sometimes generates irreducible
control flow.
Context: https://github.com/emscripten-core/emscripten/pull/8233
Reviewers: kripken, dschuff
Subscribers: sunfish, sbc100, jgravelle-google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58953
llvm-svn: 355437
|
| |
|
|
|
|
|
|
| |
immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary."
This caused the first matcher in the isel table for many targets to Opc_Scope instead of Opc_SwitchOpcode. This leads to a significant increase in isel match failures.
llvm-svn: 355433
|
| |
|
|
|
|
|
|
|
|
|
|
| |
single array.
These arrays are both keyed by CPU name and go into the same tablegenerated file. Merge them so we only need to store keys once.
This also removes a weird space saving quirk where we used the ProcDesc.size() to create to build an ArrayRef for ProcSched.
Differential Revision: https://reviews.llvm.org/D58939
llvm-svn: 355431
|
| |
|
|
|
|
|
|
|
|
| |
The variable X86DomainReassignment::EnclosedEdges is used to store registers that have been enclosed in some closure, so those registers will be ignored when create new closures. But there is no registers has ever been put into this set, so a single register can be enclosed in multiple closures, it significantly increase compile time.
This patch adds a register into EnclosedEdges when it is enclosed into a closure.
Differential Revision: https://reviews.llvm.org/D58646
llvm-svn: 355430
|
| |
|
|
|
|
|
|
|
|
|
|
| |
remove fields from the stack tables that aren't needed for CPUs
The description for CPUs was just the CPU name wrapped with "Select the " and " processor". We can just do that directly in the help printer instead of making a separate version in the binary for each CPU.
Also remove the Value field that isn't needed and was always 0.
Differential Revision: https://reviews.llvm.org/D58938
llvm-svn: 355429
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to MCSubtargetInfo.h. Move all code that operates on ProcFeatures and ProcDesc arrays to MCSubtargetInfo.
The SubtargetFeature class managed a list of features as strings. And it also had functions for setting bits in a FeatureBitset.
The methods that operated on the Feature list as strings are used in other parts of the backend. But the parts that operate on FeatureBitset are very tightly coupled to MCSubtargetInfo and requires passing in the arrays that MCSubtargetInfo owns. And the same struct type is used for ProcFeatures and ProcDesc.
This has led to MCSubtargetInfo having 2 arrays keyed by CPU name. One containing a mapping from a CPU name to its features. And one containing a mapping from CPU name to its scheduler model.
I would like to make a single CPU array containing all CPU information and remove some unneeded fields the ProcDesc array currently has. But I don't want to make SubtargetFeatures.h have to know about the scheduler model type and have to forward declare or pull in the header file.
Differential Revision: https://reviews.llvm.org/D58937
llvm-svn: 355428
|
| |
|
|
|
|
| |
Fixes undefined value verifier error.
llvm-svn: 355426
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D58870
llvm-svn: 355425
|
| |
|
|
|
|
|
|
| |
We already do this for 16/32/64 as well as 8-bit add with register/immediate. Might as well do it for 8-bit INC/DEC too.
Differential Revision: https://reviews.llvm.org/D58869
llvm-svn: 355424
|
| |
|
|
|
|
|
|
| |
We already support 8-bits adds in convertToThreeAddress. But we can also support 8-bit OR if the bits are disjoint. We already do this for 16/32/64.
Differential Revision: https://reviews.llvm.org/D58863
llvm-svn: 355423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently one can concatenate strings using hash(#),
but not lists, although that would be a natural thing to do.
This patch allows one to write something like:
def : A<!listconcat([1,2], [3,4])>;
simply as :
def : A<[1,2] # [3,4]>;
This was missing feature was highlighted by Nicolai
at FOSDEM talk.
Reviewed by: nhaehnle, hfinkel
Differential Revision: https://reviews.llvm.org/D58895
llvm-svn: 355414
|
| |
|
|
| |
llvm-svn: 355411
|
| |
|
|
|
|
|
|
|
|
|
| |
This broke test-suite::aarch64_neon_intrinsics.test
Reverting while I look into it.
Example failure:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/17740
llvm-svn: 355408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Ensure order of operands in DPP atomic optimizer final WWM step is appropriate for sub instructions.
Change-Id: I631d050e1c00a3b4bc7c11a90437064403c4cf30
Reviewers: sheredom, tpr
Reviewed By: sheredom
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, t-tye, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58900
llvm-svn: 355394
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A SCEV is not low-cost just because you can divide it by a power of 2. We need to also
check what we are dividing to make sure it too is not a high-code expansion. This helps
to not expand the exit value of certain loops, helping not to bloat the code.
The change in no-iv-rewrite.ll is reverting back to what it was testing before rL194116,
and looks a lot like the other tests in replace-loop-exit-folds.ll.
Differential Revision: https://reviews.llvm.org/D58435
llvm-svn: 355393
|
| |
|
|
| |
llvm-svn: 355387
|
| |
|
|
|
|
|
|
|
|
|
| |
When lowering a select_cc node where the true and false values are of type f16,
we can't use a general conditional move because the FP16 instructions do not
support conditional execution. Instead, we must ensure that the condition code
is one of the four supported by the VSEL instruction.
Differential revision: https://reviews.llvm.org/D58813
llvm-svn: 355385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In some cases the KILL was causing a hazard to be introduced as these were
scheduled into hazard slots, but don't result in an instruction.
KILL shouldn't be considered for hazard recognition.
Change-Id: Ib6d2a2160f8c94cd0ce611ab198c7e4f46aeffcf
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, tpr, t-tye, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58898
llvm-svn: 355384
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D58428
llvm-svn: 355378
|
| |
|
|
|
|
|
|
|
| |
Implement MCInstrAnalysis for AMDGPU, with default implementations save
for `evaluateBranch`.
Differential Revision: https://reviews.llvm.org/D58400
llvm-svn: 355373
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: chandlerc, arsenm
Reviewed By: arsenm
Subscribers: wdng, arsenm, mcrosier, jlebar, bixia, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58887
llvm-svn: 355362
|
| |
|
|
|
|
|
|
|
|
|
|
| |
when AVX2 is available and execution domain fixing will do the right thing
We have quite a few cases of using FP instructions for integer operations when only AVX1 is available. Then we switch to integer instructions with AVX2. In a lot of these cases execution domain fixing will take care of turning FP instructions into integer if its profitable.
With this patch we just keep on using the FP instructions even with AVX2. I've only handled some cases that don't require messing with patterns that are defined in the instruction definition. Those will require more subtle multiclass work possibly involving null_frag, hasSideEffects = 0, etc.
Differential Revision: https://reviews.llvm.org/D58470
llvm-svn: 355361
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If There is no types/non-empty strings, do not generate
.BTF section. If there is no func_info/line_info, do
not generate .BTF.ext section.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D58936
llvm-svn: 355360
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
They simply shuffle bits. MSan needs to do the same with shadow bits,
after making sure that the shuffle mask is fully initialized.
Reviewers: pcc, vitalybuka
Subscribers: hiraditya, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58858
llvm-svn: 355348
|
| |
|
|
| |
llvm-svn: 355346
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The test is reduced from an example in the post-commit thread for:
rL354746
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190304/632396.html
While we must avoid dying here, the real question should be:
Why is non-canonical and/or degenerate code making it to CGP when
using the new pass manager?
llvm-svn: 355345
|