| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 307523
|
| |
|
|
| |
llvm-svn: 307522
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 307521
|
| |
|
|
|
|
|
|
|
|
| |
past behavior of returning an unsupported indication to the caller instead.
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?
llvm-svn: 307520
|
| |
|
|
|
|
| |
This test pretty clearly should be calling 'maxnum' here. =]
llvm-svn: 307519
|
| |
|
|
|
|
|
|
| |
On Apple the test feature 'sanitizer-new-delete' was incorrectly
getting added to the LIT feature set, which mistakenly caused tests
to be disabled when using UBSAN (the feature is only needed with ASAN/MSAN/TSAN).
llvm-svn: 307518
|
| |
|
|
| |
llvm-svn: 307517
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 307516
|
| |
|
|
|
|
| |
were committed
llvm-svn: 307515
|
| |
|
|
| |
llvm-svn: 307514
|
| |
|
|
|
|
|
|
|
| |
coroutine_traits for member functions.
This patch was originally from Toby Allsopp, but I hijacked it and
fixed it up with his permission.
llvm-svn: 307513
|
| |
|
|
|
|
|
| |
Patch by Tatyana Krasnukha
Differential Revision: https://reviews.llvm.org/D34942
llvm-svn: 307512
|
| |
|
|
| |
llvm-svn: 307511
|
| |
|
|
| |
llvm-svn: 307510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patches improves the hashing subsequences in CompoundStmts by incrementally hashing all subsequences with the same starting position. This results in a reduction of the time for this constraint while running over SQLite from 1.10 seconds to 0.55 seconds (-50%).
Reviewers: NoQ
Reviewed By: NoQ
Subscribers: cfe-commits, xazax.hun, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D34364
llvm-svn: 307509
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 307508
|
| |
|
|
| |
llvm-svn: 307507
|
| |
|
|
|
|
|
|
| |
maximum level support before accessing the leaf. Rename level to leaf everywhere.
This matches gcc behavior.
llvm-svn: 307506
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D32385
llvm-svn: 307505
|
| |
|
|
|
|
|
|
|
|
| |
GHC 8.4 will know how to use YMM and ZMM registers for calls.
Submitted on behalf of @bgamari (Ben Gamari)
Differential Revision: https://reviews.llvm.org/D34854
llvm-svn: 307504
|
| |
|
|
|
|
| |
Broken due to r307259.
llvm-svn: 307503
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 307502
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: We probably want to use this useful templates in other pieces of code (e.g. the one from D34329), so we should make this public.
Reviewers: NoQ
Reviewed By: NoQ
Subscribers: cfe-commits, xazax.hun, v.g.vassilev, johannes
Differential Revision: https://reviews.llvm.org/D34880
llvm-svn: 307501
|
| |
|
|
|
|
| |
Show poor codegen on KNL targets as mentioned on D35179
llvm-svn: 307500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since r306667, propagateInvalidStmtDomains gets a reference to an
InvalidDomainMap. As part of the branch leading to return false, the respective
domain is freed. It is, however, not removed from the InvalidDomainMap, leaking
a pointer to a freed object which results in a use-after-free. Fix this be
removing the domain from the map before returning.
We tried to derive a test case that reliably failes, but did not succeed in
producing one. Hence, for now the failures in our LNT bots must be sufficient
to keep this issue tested.
Reviewers: grosser, Meinersbur, bollu
Subscribers: bollu, nandini12396, pollydev, llvm-commits
Differential Revision: https://reviews.llvm.org/D34971
llvm-svn: 307499
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 307498
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 307497
|
| |
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 307496
|
| |
|
|
|
|
|
|
| |
getHostCPUName.
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.
llvm-svn: 307495
|
| |
|
|
| |
llvm-svn: 307494
|
| |
|
|
|
|
|
| |
function template to simplify building a quick object with a set marked
as preserved.
llvm-svn: 307493
|
| |
|
|
|
|
| |
isIntegerTy(unsigned), but also works for vectors.
llvm-svn: 307492
|
| |
|
|
|
|
| |
Type::isPtrOrPtrVectorTy/isIntOrIntVectorTy/isFPOrFPVectorTy to shorten code. NFC
llvm-svn: 307491
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 307490
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: FastISel was marked as failed in case instruction selection succeeded.
Reviewers: qcolombet, zvi, rovka, ab
Reviewed By: zvi
Subscribers: javed.absar, ab, qcolombet, bogner, llvm-commits
Differential Revision: https://reviews.llvm.org/D34438
llvm-svn: 307489
|
| |
|
|
|
|
| |
sucessor -> successor
llvm-svn: 307488
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 307487
|
| |
|
|
|
|
|
|
|
|
| |
of PR33721 by making sure that we have integer types before doing select C, -1, 0 -> sext C to int
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.
llvm-svn: 307486
|
| |
|
|
| |
llvm-svn: 307485
|
| |
|
|
|
|
| |
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.
llvm-svn: 307484
|
| |
|
|
| |
llvm-svn: 307483
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D35158
llvm-svn: 307482
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D35158
llvm-svn: 307481
|
| |
|
|
| |
llvm-svn: 307480
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 307479
|
| |
|
|
|
|
|
|
| |
Summary: Fixed a bug that -foo=bar wasn't handled properly on old version of bash.
Differential Revision: https://reviews.llvm.org/D34927
llvm-svn: 307478
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and indvars"
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
llvm-svn: 307477
|
| |
|
|
|
|
| |
Bots are failing because of the additional checks.
llvm-svn: 307476
|
| |
|
|
|
|
|
|
|
| |
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?
llvm-svn: 307475
|
| |
|
|
| |
llvm-svn: 307474
|