Remove the type alias now that the std::variant aspect is gone, directly
using std::vector in the few places that need it is more idiomatic.
Move a routine from a core header to single user.
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.
Currently, GlobalObject has an "alignment" property... but it's
basically nonsense: alignment doesn't mean the same thing for variables
and functions, and it's completely meaningless for ifuncs.
This "removes" (actually marking protected) the methods from
GlobalObject, adds the relevant methods to Function and GlobalVariable,
and adjusts the code appropriately.
This should make future alignment-related cleanups easier.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
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.
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 makes it easier to reduce llvm-reduce with llvm-reduce to filter
cases where the input reduced too much.
Not sure if it's possible to test the exit code in lit.
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.
