| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 348407
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D54980
This provides a standard API across GISel passes to observe and notify
passes about changes (insertions/deletions/mutations) to MachineInstrs.
This patch also removes the recordInsertion method in MachineIRBuilder
and instead provides method to setObserver.
Reviewed by: vkeles.
llvm-svn: 348406
|
|
|
|
|
|
|
|
|
|
| |
Treat terminators which resume exception propagation as returning instructions
(at least, for the purposes of marking outlined functions `noreturn`). This is
to avoid inserting traps after calls to outlined functions which unwind.
rdar://46129950
llvm-svn: 348404
|
|
|
|
|
|
|
| |
Reword the description of the feature that enables custom handling of cheap
instructions.
llvm-svn: 348398
|
|
|
|
|
|
|
|
|
|
|
| |
Some gardening/refactoring.
It's cleaner to copy the instructions into the MachineFunction using the first
candidate instead of going to the mapper.
Also, by doing this we can remove the Seq member from OutlinedFunction entirely.
llvm-svn: 348390
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR39893)
Because we're potentially peeking through a bitcast in this transform,
we need to use overall bitwidths rather than number of elements to
determine when it's safe to proceed.
Should fix:
https://bugs.llvm.org/show_bug.cgi?id=39893
llvm-svn: 348383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: debug intrinsics might be marked norecurse to enable the caller function to be norecurse and optimized if needed. This avoids code gen optimisation differences when -g is used, as in globalOpt.cpp:processInternalGlobal checks.
Reviewers: chandlerc, jmolloy, aprantl
Reviewed By: aprantl
Subscribers: aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D55187
llvm-svn: 348381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever we effectively take the address of a basic block we need to
manually update that basic block to reflect that fact or later passes
such as tail duplication and tail merging can break the invariants of
the code. =/ Sadly, there doesn't appear to be any good way of
automating this or even writing a reasonable assert to catch it early.
The change seems trivially and obviously correct, but sadly the only
really good test case I have is 1000s of basic blocks. I've tried
directly writing a test case that happens to make tail duplication do
something that crashes later on, but this appears to require an
*amazingly* complex set of conditions that I've not yet reproduced.
The change is technically covered by the tests because we mark the
blocks as having their address taken, but that doesn't really count as
properly testing the functionality.
llvm-svn: 348374
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D55314
llvm-svn: 348371
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tests here are based on the motivating cases from D54827.
More background:
1. We don't get these cases in general with SimplifyCFG because the root
of the pattern match is an icmp, not a branch. I'm not sure how often
we encounter this pattern vs. the seemingly more likely case with
branches, but I don't see evidence to leave the minimal pattern
unoptimized.
2. This has a chance of increasing compile-time because we're using a
ValueTracking call to handle the match. The motivating cases could be
handled with a simpler pair of calls to isImpliedTrueByMatchingCmp/
isImpliedFalseByMatchingCmp, but I saw that we have a more
comprehensive wrapper around those, so we might as well use it here
unless there's evidence that it's significantly slower.
3. Ideally, we'd handle the fold to constants in InstSimplify, but as
with the existing code here, we could extend this to handle cases
where the result is not a constant, but a new combined predicate.
That would mean splitting the logic across the 2 passes and possibly
duplicating the pattern-matching cost.
4. As mentioned in D54827, this seems like the kind of thing that should
be handled in Correlated Value Propagation, but that pass is currently
limited to dealing with instructions with constant operands, so extending
this bit of InstCombine is the smallest/easiest way to get these patterns
optimized.
llvm-svn: 348367
|
|
|
|
|
|
|
|
| |
Prep work for PR38243 - mainly adding comments on where we need to add modulo support (doing so at the moment causes massive codegen regressions).
I've also consistently added support for modulo folding for uniform constants (although at the moment we have no way to trigger this) and removed the old assertions.
llvm-svn: 348366
|
|
|
|
|
|
|
|
| |
SimplifyDemandedVectorElts
These have no test coverage and the KnownZero flags can't be guaranteed unlike SIGN/ZERO_EXTEND cases.
llvm-svn: 348361
|
|
|
|
|
|
|
|
|
|
| |
This is an initial patch to add a minimum level of support for funnel shifts to the SelectionDAG and to begin wiring it up to the X86 SHLD/SHRD instructions.
Some partial legalization code has been added to handle the case for 'SlowSHLD' where we want to expand instead and I've added a few DAG combines so we don't get regressions from the existing DAG builder expansion code.
Differential Revision: https://reviews.llvm.org/D54698
llvm-svn: 348353
|
|
|
|
|
|
|
|
|
|
| |
Error was:
/home/buildslave/slave_as-bldslv8/lld-perf-testsuite/llvm/lib/MC/MCFragment.cpp:241:22: error: field 'Offset' will be initialized after field 'LayoutOrder' [-Werror,-Wreorder]
Atom(nullptr), Offset(~UINT64_C(0)), LayoutOrder(0) {
http://lab.llvm.org:8011/builders/lld-perf-testsuite/builds/9628/steps/build-bin%2Flld/logs/stdio
llvm-svn: 348351
|
|
|
|
|
|
| |
As requested in D54698.
llvm-svn: 348350
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
debug sections."
The patch triggered an unrelated msan issue: LayoutOrder variable was not initialized.
(http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/26794/steps/check-llvm%20msan/logs/stdio)
It was fixed.
Original commit message:
MC has code that pre-creates few debug sections:
https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCObjectFileInfo.cpp#L396
If users code has a reference to such section but does not redefine it,
MC code currently asserts, because still thinks they are normally defined.
The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D55173
----
Modified : /llvm/trunk/lib/MC/ELFObjectWriter.cpp
Added : /llvm/trunk/test/MC/ELF/undefined-debug.s
llvm-svn: 348349
|
|
|
|
|
|
|
|
| |
Fix potential issue with the ISD::INSERT_VECTOR_ELT case tweaking the DemandedElts mask instead of using a local copy - so later uses of the mask use the tweaked version.....
Noticed while investigating adding zero/undef folding to SimplifyDemandedVectorElts and the altered DemandedElts mask was causing mismatches.
llvm-svn: 348348
|
|
|
|
|
|
|
|
| |
The only things that are different from arm are:
* different opcodes for calls and returns
* Thumb calls take predicate operands
llvm-svn: 348347
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The remaining code paths that ControlFlowHoisting introduced that were
not disabled, increased compile time by 3x for some benchmarks.
The time is spent in DominatorTree updates.
Reviewers: john.brawn, mkazantsev
Subscribers: sanjoy, jlebar, llvm-commits
Differential Revision: https://reviews.llvm.org/D55313
llvm-svn: 348345
|
|
|
|
|
|
|
|
|
|
| |
Functions annotated with `__fastcall` or `__attribute__((__fastcall__))`
or `__attribute__((__swiftcall__))` may contain SEH handlers even on
Win64. This matches the behaviour of cl which allows for
`__try`/`__except` inside a `__fastcall` function. This was detected
while trying to self-host clang on Windows ARM64.
llvm-svn: 348337
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in post-RA LICM
It looks like MCRegAliasIterator can visit the same physical register twice. When this happens in this code in LICM we end up setting the PhysRegDef and then later in the same loop visit the register again. Now we see that PhysRegDef is set from the earlier iteration so now set PhysRegClobber.
This patch splits the loop so we have one that uses the previous value of PhysRegDef to update PhysRegClobber and second loop that updates PhysRegDef.
The X86 atomic test is an improvement. I had to add sideeffect to the two shrink wrapping tests to prevent hoisting from occurring. I'm not sure about the AMDGPU tests. It looks like the branch instruction changed at end the of the loops. And in the branch-relaxation test I think there is now "and vcc, exec, -1" instruction that wasn't there before.
Differential Revision: https://reviews.llvm.org/D55102
llvm-svn: 348330
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis, m.ostapenko, ygribov
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D55157
llvm-svn: 348327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a 64k limit on the number of SDNode operands, and some very large
functions with 64k or more loads can cause crashes due to this limit being hit
when a TokenFactor with this many operands is created. To fix this, create
sub-tokenfactors if we've exceeded the limit.
No test case as it requires a very large function.
rdar://45196621
Differential Revision: https://reviews.llvm.org/D55073
llvm-svn: 348324
|
|
|
|
|
|
|
|
|
|
| |
This breaks C and C++ semantics because it can cause the address
of the global inside the module to differ from the address outside
of the module.
Differential Revision: https://reviews.llvm.org/D55237
llvm-svn: 348321
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously disabled this in r323371 because of a bug where we selected an
extending load, but didn't delete the old G_LOAD, resulting in two loads being
generated for volatile loads.
Since we now have dedicated G_SEXTLOAD/G_ZEXTLOAD operations, and that the
tablegen patterns should no longer be able to select (ext(load x)) patterns, it
should be safe to re-enable it.
The old test case should still work as expected.
llvm-svn: 348320
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis, m.ostapenko, ygribov
Subscribers: mehdi_amini, kubamracek, hiraditya, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D55156
llvm-svn: 348316
|
|
|
|
|
|
| |
Drive by clean up for Windows ARM64 variadic CC (NFC).
llvm-svn: 348310
|
|
|
|
|
|
|
|
|
|
|
| |
Previously these were dropped. We now understand them sufficiently
well to start emitting them. From the debugger's perspective, this
now enables us to have debug info about typedefs (both global and
function-locally scoped)
Differential Revision: https://reviews.llvm.org/D55228
llvm-svn: 348306
|
|
|
|
| |
llvm-svn: 348304
|
|
|
|
|
|
|
|
| |
Change the default for PowerPC LE to -fno-PIC.
Differential Revision: https://reviews.llvm.org/D53383
llvm-svn: 348298
|
|
|
|
|
|
|
| |
The old function underspecified the return type, took an unused parameter,
and had a misleading name.
llvm-svn: 348292
|
|
|
|
| |
llvm-svn: 348288
|
|
|
|
| |
llvm-svn: 348286
|
|
|
|
|
|
|
|
|
|
| |
Currently if you use -{start,stop}-{before,after}, it picks
the first instance with the matching pass name. If you run
the same pass multiple times, there's no way to distinguish them.
Allow specifying a run index wih ,N to specify which you mean.
llvm-svn: 348285
|
|
|
|
|
|
|
|
| |
Move it out from under the constant check, reorder
predicates, add comments. This makes it easier to
extend to handle the non-constant case.
llvm-svn: 348284
|
|
|
|
|
|
| |
Moves existing SimplifyDemandedBits call out of combineMOVMSK and add SimplifyDemandedVectorElts call based on the sign bits we need.
llvm-svn: 348282
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r348203.
Reason: this produces absolute paths in .gcno files, breaking us
internally as we rely on them being consistent with the filenames passed
in the command line.
Also reverts r348157 and r348155 to account for revert of r348154 in
clang repository.
llvm-svn: 348279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a potential small enhancement to this code that could
solve the cases currently under proposal in D54827 via SimplifyCFG.
Whether instcombine should be doing this kind of semi-non-local
analysis in the first place is an open question, but separating
the logic out can only help if/when we decide to move it to a
different pass.
AFAICT, any proposal to do this in SimplifyCFG could also be seen
as an overreach + it would be incomplete to start the fold from a
branch rather than an icmp.
There's another question here about the code for processUGT_ADDCST_ADD().
That part may be completely dead after rL234638 ?
llvm-svn: 348273
|
|
|
|
| |
llvm-svn: 348269
|
|
|
|
| |
llvm-svn: 348267
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Teach SimpleLoopUnswitch to preserve MemorySSA.
Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits
Differential Revision: https://reviews.llvm.org/D47022
llvm-svn: 348263
|
|
|
|
| |
llvm-svn: 348256
|
|
|
|
| |
llvm-svn: 348254
|
|
|
|
|
|
| |
The GetSplatValue/IsSplatVector call will call this anyhow and the later code is just for a v2i64 type so doesn't need it.
llvm-svn: 348253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR17686)
PR17686 demonstrates that for some targets FP exceptions can fire in cases where the FP_TO_UINT is expanded using a FP_TO_SINT instruction.
The existing code converts both the inrange and outofrange cases using FP_TO_SINT and then selects the result, this patch changes this for 'strict' cases to pre-select the FP_TO_SINT input and the offset adjustment.
The X87 cases don't need the strict flag but generates much nicer code with it....
Differential Revision: https://reviews.llvm.org/D53794
llvm-svn: 348251
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch splits backend features currently
hidden behind architecture versions.
For example, currently the only way to activate
complex numbers extension is targeting an v8.3
architecture, where after the patch this extension
can be added separately.
This refactoring is required by the new command lines proposal:
http://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html
Reviewers: DavidSpickett, olista01, t.p.northover
Subscribers: kristof.beyls, bryanpkc, javed.absar, pbarrio
Differential revision: https://reviews.llvm.org/D54633
........
This has been causing buildbots failures for the past 24 hours: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/14386
llvm-svn: 348249
|
|
|
|
|
|
|
|
|
|
| |
sections."
It broke msan and asan bots it seems:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/26794/steps/check-llvm%20msan/logs/stdio
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/20993/steps/ninja%20check%201/logs/stdio
llvm-svn: 348248
|
|
|
|
|
|
|
|
| |
Add support for ISD::*_EXTEND and ISD::*_EXTEND_VECTOR_INREG opcodes.
The extra broadcast in trunc-subvector.ll will be fixed in an upcoming patch.
llvm-svn: 348246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MC has code that pre-creates few debug sections:
https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCObjectFileInfo.cpp#L396
If users code has a reference to such section but does not redefine it,
MC code currently asserts, because still thinks they are normally defined.
The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D55173
llvm-svn: 348243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue is the following.
DWARF 2 used version 1 for .debug_frame.
(Appendix G, p. 416 http://dwarfstd.org/doc/DWARF5.pdf)
lib/MC now always sets version 1 for .eh_frame (and sets 1-4 versions for .debug_frame correctly):
https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1530
https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1562
https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1602
In version 1, return_address_register was defined as ubyte, while other versions
switched to uleb128.
(p 62, http://www.dwarfstd.org/doc/dwarf-2.0.0.pdf)
Patch teaches llvm-dwarfdump about this difference.
Differential revision: https://reviews.llvm.org/D54860
llvm-svn: 348242
|