Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307532 91177308-0d34-0410-b5e6-96231b3b80d8
Variable was called 'Name' and contained text
name of relocation type. Problem was that
outside of this error handling scope we already
have different 'Name' variable that contains
section name.
Change helps to avoid confusion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307530 91177308-0d34-0410-b5e6-96231b3b80d8
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307529 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Mark G_ZEXT/G_SEXT i1 to i8/i16, i8 to i16 as legal.
Support G_ZEXT i1 to i8/i16 instruction selection ( C++ code).
This patch requred to support G_LOAD/G_STORE i1.
Reviewers: zvi, guyblank
Reviewed By: guyblank
Subscribers: rovka, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D35177
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307526 91177308-0d34-0410-b5e6-96231b3b80d8
r274441 introduced Chapter 10 of "Implementing a Language with LLVM" tutorial,
which caused all files in the tutorial to start using two digit numbering. But
many links were not changed and therefore appear to be broken. This patch
addresses described issue.
As a result, following command does not produce any output anymore:
$ grep -nR '<LangImpl[0-9].html>' ./docs/tutorial/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307525 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This solves PR33641.
When removing a dead argument we must also handle possibly existing calls
to llvm.dbg.value that use the removed argument. Now we change the use
of the otherwise dead argument to an undef for some other pass to cleanup
later.
If the calls are left untouched, they will later on cause errors:
"function-local metadata used in wrong function"
since the ArgumentPromotion rewrites the code by creating a new function
with the wanted signature, but the metadata is not recreated so the new
function may then erroneously use metadata from the old function.
Reviewers: mstorsjo, rnk, arsenm
Reviewed By: rnk
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D34874
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307521 91177308-0d34-0410-b5e6-96231b3b80d8
These asserts could only occur if we fail to properly detect the compiler, but an assert is not a good way to do that because it doesn't work in release builds.
I wonder if we could use #error?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307520 91177308-0d34-0410-b5e6-96231b3b80d8
Reduces llvm-profdata memory usage on a large profile from 7.8GB to 5.1GB.
The ProfData API now supports reporting all the errors/warnings rather
than only the first, though llvm-profdata ignores everything after the
first for now to preserve existing behavior. (if there's a desire for
other behavior, happy to implement that - but might be as well left for
a separate patch)
Reviewers: davidxl
Differential Revision: https://reviews.llvm.org/D35149
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307516 91177308-0d34-0410-b5e6-96231b3b80d8
WidenVSELECTAndMask can fold (and it folds in this case) so we
get a BUILD_VECTOR of constants as mask. convertMask() seems to
work fine when the input is a vector of constants, and we still
need to call it to extend/add elements at the end. but the current
code just asserts on anything but a SETCC or AND/OR/XOR of 2xSETCC.
This change was discussed briefly with Simon Pilgrim, who also
suggests we might consider dropping this assertion in the future.
Fixes PR33715.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307508 91177308-0d34-0410-b5e6-96231b3b80d8
This change fixes a bug in SelectionDAGBuilder::visitInsertValue and SelectionDAGBuilder::visitExtractValue where constant expressions (InsertValueConstantExpr and ExtractValueConstantExpr) would be treated as non-constant instructions (InsertValueInst and ExtractValueInst). This bug resulted in an incorrect memory access, which manifested as an assertion failure in SDValue::SDValue.
Fixes PR#33094.
Submitted on behalf of @Praetonus (Benoit Vey)
Differential Revision: https://reviews.llvm.org/D34538
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307502 91177308-0d34-0410-b5e6-96231b3b80d8
invalidation of analyses when merging SCCs.
While I've added a bunch of testing of this, it takes something much
more like the inliner to really trigger this as you need to have
partially-analyzed SCCs with updates at just the right time. So I've
added a direct test for this using the inliner and verifying the
domtree. Without the changes here, this test ends up finding a stale
dominator tree.
However, to handle this properly, we need to invalidate analyses
*before* merging the SCCs. After talking to Philip and Sanjoy about this
they convinced me this was the right approach. To do this, we need
a callback mechanism when merging SCCs so we can observe the cycle that
will be merged before the merge happens. This API update ended up being
surprisingly easy.
With this commit, the new PM passes the test-suite again. It hadn't
since MemorySSA was enabled for EarlyCSE as that also will find this bug
very quickly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307498 91177308-0d34-0410-b5e6-96231b3b80d8
dependencies between analyses.
This uncovers even more issues with the proxies and the splitting apart
of SCCs which are fixed in this patch. I discovered this while trying to
add more rigorous testing for a change I'm making to the call graph
update invalidation logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307497 91177308-0d34-0410-b5e6-96231b3b80d8
by a valid octal digit.
The length argument shows that this was in fact the intent.
This was pointed out in IRC, thanks to eddyb!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307496 91177308-0d34-0410-b5e6-96231b3b80d8
Users of getHostCPUName should also use getHostCPUFeatures which will take care of making sure avx512 is disabled if the CPU doesn't support it. This is consistent with what we do for other CPUs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307495 91177308-0d34-0410-b5e6-96231b3b80d8
The internal representation has a natural way to handle this and it
seems nicer than having to wrap this in an optional (with its own
separate flag).
This also matches how std::function works.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307490 91177308-0d34-0410-b5e6-96231b3b80d8
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307487 91177308-0d34-0410-b5e6-96231b3b80d8
I recently changed m_One and m_AllOnes to use Constant::isOneValue/isAllOnesValue which work on floating point values too. The original implementation looked specifically for ConstantInt scalars and splats. So I'm guessing we are accidentally trying to issue sext/zexts on floating point types now.
Hopefully I figure out how to reproduce the failure from the PR soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307486 91177308-0d34-0410-b5e6-96231b3b80d8
Add breaks - doesn't affect results as both GPR/FPU both check for 32/64 bit sizes. So will still default to GenericOps in the same way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307484 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We don't want to autocomplete flags whose Flags class has `NoDriverOption` when argv[1] is not `-cc1`.
Another idea for this implementation is to make --autocomplete a cc1
option and handle it in clang Frontend, by porting --autocomplete
handler from Driver to Frontend, so that we can handle Driver options
and CC1 options in unified manner.
Differential Revision: https://reviews.llvm.org/D34770
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307479 91177308-0d34-0410-b5e6-96231b3b80d8
The patch was reverted due to a bug. The bug was that if the IV is the 2nd operand of the icmp
instruction, then the "Pred" variable gets swapped and differs from the instruction's predicate.
In this patch we use the original predicate to do the transformation.
Also added a test case that exercises this situation.
Differentian Revision: https://reviews.llvm.org/D35107
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307477 91177308-0d34-0410-b5e6-96231b3b80d8
I'm looking at a cmp transform in InstCombine that would affect these tests,
but it's hard to know if it makes things better or worse without seeing the
full IR. OTOH, maybe these tests shouldn't be running a bunch of transform
passes in the first place?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307475 91177308-0d34-0410-b5e6-96231b3b80d8
x86 scalar select-of-constants (Cond ? C1 : C2) combining/lowering is a mess
with missing optimizations. We handle some patterns, but miss logical variants.
To clean that up, we should convert all select-of-constants to logic/math and
enhance the combining for the expected patterns from that. Selecting 0 or -1
needs extra attention to produce the optimal code as shown here.
Attempt to verify that all of these IR forms are logically equivalent:
http://rise4fun.com/Alive/plxs
Earlier steps in this series:
rL306040
rL306072
rL307404 (D34652)
As acknowledged in the earlier review, there's a possibility that some Intel
uarch would prefer to produce an xor to clear the fake register operand with
sbb %eax, %eax. This will likely need to be addressed in a separate pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307471 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
(re)definition of _RESTRICT_KYWD rightfully causes a warning message during the Solaris build.
This hack is not needed if build compiler is properly configured (.e.g /usr/bin/gcc) so just remove it.
Reviewers: ro, mgorny, krytarowski, joerg
Reviewed By: joerg
Subscribers: quenelle, llvm-commits
Patch by Fedor Sergeev (Oracle).
Differential Revision: https://reviews.llvm.org/D35054
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307469 91177308-0d34-0410-b5e6-96231b3b80d8
The CPU name is really just used for scheduler and other microarchitectural optimizations. The feature flags should be determined by getHostCPUFeatures which should always be used with getHostCPUName. Trying to alter CPU name strings to control features just isn't practical.
Most of these types of things were removed from Intel CPUs a while ago.
This is part of my plan to bring compiler-rt's cpu_model.c file up to date with the equivalent functionality in libgcc. A lot of the code in that file is copied from Host.cpp and we want to keep them reasonably in sync.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307467 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 147f45ff24456aea59575fa4ac16c8fa554df46a.
Revert "Revert "Revert "Revert "Replace trivial use of external rc.exe by writing our own .res file.""""
This reverts commit 61a90a67ed54a1f0dfeab457b65abffa129569e4.
The patches were intially reverted because they were causing a failure
on CrWinClangLLD. Unfortunately, this was done haphazardly and didn't
compile, so the revert was reverted again quickly to fix this. One that
was done, the revert of the revert was itself reverted. This allowed me
to finally fix the actual bug in r307452. This patch re-enables the
code path that had originally been causing the bug, now that it (should)
be fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307460 91177308-0d34-0410-b5e6-96231b3b80d8
