Now that #149310 has restricted lifetime intrinsics to only work on
allocas, we can also drop the explicit size argument. Instead, the size
is implied by the alloca.
This removes the ability to only mark a prefix of an alloca alive/dead.
We never used that capability, so we should remove the need to handle
that possibility everywhere (though many key places, including stack
coloring, did not actually respect this).
The lifetime argument is now required to be an alloca, so we should not
try to replace it with a constant.
We also shouldn't try to change the size argument to zero/one, similar
to how we avoid zero-size allocas.
The lifetime argument is now required to be an alloca, so do not try to
convert it to a function argument.
The reduction is now going to leave behind an unused alloca with
lifetime markers, which should be cleaned up separately.
I'd say this fixes https://github.com/llvm/llvm-project/issues/93713. It
doesn't remove the lifetime markers as the issue suggests, but at least
they're now not going to be on the argument.
Reapply "IR: Remove uselist for constantdata (#137313)"
This reverts commit 5936c02c8b9c6d1476f7830517781ce8b6e26e75.
Fix checking uselists of constants in assume bundle queries
This is a resurrected version of the patch attached to this RFC:
https://discourse.llvm.org/t/rfc-constantdata-should-not-have-use-lists/42606
In this adaptation, there are a few differences. In the original patch, the Use's
use list was replaced with an unsigned* to the reference count in the value. This
version leaves them as null and leaves the ref counting only in Value.
Remove use-lists from instances of ConstantData (which are shared
across modules and have no operands).
To continue supporting most of the use-list API, store a ref-count in
place of the use-list; this is for API like Value::use_empty and
Value::hasNUses. Operations that actually need the use-list -- like
Value::use_begin -- will assert.
This change has three benefits:
1. The compiler output cannot in any way depend on the use-list order
of instances of ConstantData.
2. There's no use-list traffic when adding and removing simple
constants from operand lists (although there is ref-count traffic;
YMMV).
3. It's cheaper to serialize use-lists (since we're no longer
serializing the use-list order of things like i32 0).
The downside is that you can't look at all the users of ConstantData,
but traversals of users of i32 0 are already ill-advised.
Possible follow-ups:
- Track if an instance of a ConstantVector/ConstantArray/etc. is known
to have all ConstantData arguments, and drop the use-lists to
ref-counts in those cases. Callers need to check Value::hasUseList
before iterating through the use-list.
- Remove even the ref-counts. I'm not sure they have any benefit
besides minimizing the scope of this commit, and maintaining the
counts is not free.
Fixes#58629
Co-authored-by: Duncan P. N. Exon Smith <dexonsmith@apple.com>
Use splitBasicBlock and avoid directly dealing with the specific of
how to trim the existing terminators. We just need to deal with
unconditional branch to return.
Extend the early return on value reduction to mutate the function return
type if the function has no call uses. This could be generalized to rewrite
cases where all callsites are used, but it turns out that complicates the
visitation order given we try to compute all opportunities up front.
This is enough to cleanup the common case where we end up with one
function with a return of an uninteresting constant.
Extend the instruction -> return reduction with one that inserts
return of function arguments. Not sure how useful this really is. This
has more freedom since we could insert the return anywhere in the function,
but this just inserts the return in the entry block.
In void functions, try to replace instruction uses
with a new non-void return. If the return type matches
the instruction, also try to directly return it.
This handles most of the cases, but doesn't try to handle
all of the weird exception related terminators.
Also doesn't try to replace argument uses, although it could. We
could also handle cases where we can insert a simple cast to an
original return value. I didn't think too hard about where to put this
in the default pass order. In many cases it obviates the need for most
of the CFG folds, but I've left it near the end initially.
I also think this is too aggressive about removing dead code, and
should leave existing dead code alone. I'm also not sure why we have
both "removeUnreachableBlocks" and EliminateUnreachableBlocks" in Utils.
Fixes#66039, fixes#107327
Currently BlockAddresses store both the Function and the BasicBlock they
reference, and the BlockAddress is part of the use list of both the
Function and BasicBlock.
This is quite awkward, because this is not really a use of the function
itself (and walks of function uses generally skip block addresses for
that reason). This also has weird implications on function RAUW (as that
will replace the function in block addresses in a way that generally
doesn't make sense), and causes other peculiar issues, like the ability
to have multiple block addresses for one block (with different
functions).
Instead, I believe it makes more sense to specify only the basic block
and let the function be implied by the BB parent. This does mean that we
may have block addresses without a function (if the BB is not inserted),
but this should only happen during IR construction.
This also demonstrates a bug that's a consequence of the two different
paths for the single and multithreaded cases. The parallel path goes
through bitcode serialization and does preserve the uselistorder. It
therefore survives and we can observe a reduced uselistorder with deleted
instructions. In the CloneModule case, nothing is reduced.
Commit c2e62c7 updated the ReduceDIMetadata pass to be able to remove
DIGlobalVariableExpressions from MDNode operands; it also accidentally
prevented null operands from being preserved, which results in an
assertion being triggered:
`Targets == NoChunksCounter.count() && "number of chunks changes when
reducing"'
This patch allows us to correctly preserve null operands once again.
I've not got a test case for this yet - I'm hoping this patch is just
trivially correct as-is, because I've not got the hang of reducing a
test case for llvm-reduce yet, but I can get a test case generated if
needed.
The "preserve input debug-info format" flag allowed some tooling to opt
into not seeing the new debug records yet, and to not autoupgrade. This
was good at the time, but un-necessary now that we'll be ditching
intrinsics shortly.
It also hides errors now: verify-uselistorder was hardcoding this flag
to on, and as a result it hasn't seen debug records before. Thus, we
missed a uselistorder variation: constant-expressions such as GEPs can
be contained within debug records and completely isolated from the value
hierachy, see the metadata-use-uselistorder.ll test. These Values didn't
get ordered, but were legitimate uses of constants like "i64 0", and we
now run into difficulty handling that. The patch to AsmWriter seeks
Values to order even through debug-info now.
Finally there are a few intrinsics-tests relying on this flag that we
can just delete, such as one in llvm-reduce and another few in the
LocalTest unit tests. For the fast-isel test, it was added in
https://reviews.llvm.org/D67703 explicitly for checking the size of
blocks without debug-info and in 1525abb9c94 the codepath it tests moved
towards being sunsetted. It'll be totally redundant once RemoveDIs is on
permanently.
Note that there's now no explicit test for the textual-IR autoupgrade
path. I submit that we can rely on the thousands of .ll files where
we've only been bothered to update the outputs, not the inputs, to debug
records.
After replacing the branch condition, this was calling simplifyCFG to
perform the cleanups of the branch. This is far too heavy of a hammer.
We do not want all of the extra optimizations in simplifyCFG, and
this could also leave behind dead code. Instead, minimally fold the
terminator and try to delete the newly dead code.
This is pretty much a direct copy of what bugpoint does.
This was disabled due to flakiness but I'm currently unable to
reproduce.
I'm nervous the original issue still exists. However, I downgraded the
tripped
assert in 8c18c25b1b22ea710edb40a4f167a6a8bfe6ff9d to a warning since
the same
assert can trigger for illegitimate reasons.
Fixes#64157
This wasn't checking the output for all functions.
--match-full-lines is also particularly hazardous for the
interestingness checks for avoiding asserts and broken IR.
Also add tests for some of the filtered function user types.
This wasn't covered, and is overly conservative.
If we are trying to simplify branch conditions to true, ignore branches
already set to a constant true. If we are simplifying to constant false,
ignore the already constant false cases. This saves steps in this edge
case, and avoids the side effect of running simplifycfg on blocks we
did not intend to modify.
The IR verifier will fail if there are any convergent calls without
a convergencectrl bundle, if there are any convergencectrl bundles.
With the current verifier rules, we would need to drop all the instances
of convergencectrl in the function as a set, and strip all the
convergence
token intrinsics. As such, I think it would be more appropriate to have
a
separate convergence reduction pass.
Try to reduce individual subtarget features in the "target-features"
attribute. This attempts a textual removal of the fields in the string,
not a semantic removal. Typically there's a lot of redundant feature spam
in the feature list implied by the target-cpu (which I really wish clang
would stop emitting). If we could parse these out, we could easily drop
the fields without testing anything.
The current API doesn't have a way to unset it. The query returns
an optional, but the set doesn't. Alternatively I could switch the
set to also use optional.
Not sure this is the right place to put it. This is a property
of GlobalVariable, not GlobalValue. But the ReduceGlobalVars
reduction tries to delete the value entirely.
During the transition from debug intrinsics to debug records, we used
several different command line options to customise handling: the
printing of debug records to bitcode and textual could be independent of
how the debug-info was represented inside a module, whether the
autoupgrader ran could be customised. This was all valuable during
development, but now that totally removing debug intrinsics is coming
up, this patch removes those options in favour of a single flag
(experimental-debuginfo-iterators), which enables autoupgrade, in-memory
debug records, and debug record printing to bitcode and textual IR.
We need to do this ahead of removing the
experimental-debuginfo-iterators flag, to reduce the amount of
test-juggling that happens at that time.
There are quite a number of weird test behaviours related to this --
some of which I simply delete in this commit. Things like
print-non-instruction-debug-info.ll , the test suite now checks for
debug records in all tests, and we don't want to check we can print as
intrinsics. Or the update_test_checks tests -- these are duplicated with
write-experimental-debuginfo=false to ensure file writing for intrinsics
is correct, but that's something we're imminently going to delete.
A short survey of curious test changes:
* free-intrinsics.ll: we don't need to test that debug-info is a zero
cost intrinsic, because we won't be using intrinsics in the future.
* undef-dbg-val.ll: apparently we pinned this to non-RemoveDIs in-memory
mode while we sorted something out; it works now either way.
* salvage-cast-debug-info.ll: was testing intrinsics-in-memory get
salvaged, isn't necessary now
* localize-constexpr-debuginfo.ll: was producing "dead metadata"
intrinsics for optimised-out variable values, dbg-records takes the
(correct) representation of poison/undef as an operand. Looks like we
didn't update this in the past to avoid spurious test differences.
* Transforms/Scalarizer/dbginfo.ll: this test was explicitly testing
that debug-info affected codegen, and we deferred updating the tests
until now. This is just one of those silent gnochange issues that get
fixed by RemoveDIs.
Finally: I've added a bitcode test, dbg-intrinsics-autoupgrade.ll.bc,
that checks we can autoupgrade debug intrinsics that are in bitcode into
the new debug records.
Avoid capitalized Error. This loses the "Error constructing pass pipeline"
part, and just forwards the error to the default report_fatal_error case. Not
sure if it's worth trying to keep.
The coding standards states that error messages should start with
a lowercase. Also use WithColor, and add missing test coverage for
the failed to write to output file case.
If the interestingness script is flaky, we should not assert. Print
a warning, and continue. This could still happen as a result of an
llvm-reduce bug, so make a note of that.
Add a --skip-verify-interesting-after-counting-chunks option to
avoid the extra run of the reduction script, and to silence the
warning.
In undefined mismatch cases, this was fixing the callsite to use the calling
convention of the new function. Preserve the original wrong callsite's calling
convention.
The attribute APIs make this cumbersome. There seem to be missing
overloads using AttrBuilder for the function attrs. Plus there doesn't
seem to be a direct way to set the function attrs on the call.
So far I've been unsuccessful in finding an example where the used constant
value is directly observed in the output. This avoids an assert in an intermediate
step of value replacement.
