Unlike every other analysis and transform, simplifyInstruction
permitted operating on instructions which are not inserted
into a function. This created an edge case no other code needs
to really worry about, and limited transforms in cases that
can make use of the context function. Only the inliner and a handful
of other utilities were making use of this, so just fix up these
edge cases. Results in some IR ordering differences since
cloned blocks are inserted eagerly now. Plus some additional
simplifications trigger (e.g. some add 0s now folded out that
previously didn't).
Details
Diff Detail
Event Timeline
I'm okay with making this change. People regularly rediscover it :)
You'll want to adjust the comment at https://github.com/llvm/llvm-project/blob/7f033d0f756e72359c525ed3ab371e064cf55cff/llvm/include/llvm/Analysis/InstructionSimplify.h#L22-L27.
I assume you plan to followup with a change that removes no longer needed checks from InstSimplify?
llvm/test/Transforms/Inline/call-intrinsic-is-constant.ll | ||
---|---|---|
1 ↗ | (On Diff #524867) | Precommit regenerated checks. |
llvm/test/Transforms/Inline/noalias-calls2.ll | ||
17 ↗ | (On Diff #524867) | You'll have to manually undo these for now, to preserve integrity of the checks. (Once D148216 lands, we can just use --check-globals instead.) |
llvm/docs/ReleaseNotes.rst | ||
---|---|---|
79 | too much indent | |
llvm/include/llvm/Analysis/InstructionSimplify.h | ||
22–23 | drop the "do", doesn't really make sense anymore. | |
llvm/lib/Transforms/Utils/CloneFunction.cpp | ||
689 | Can we do something like NewBB->moveBefore(NewFunc->end()) here? The nice thing about the current implementation is that it will use the same block order as in the original function, which seems like a nice property to preserve. I also expect that changing the order will result in massive codegen diffs, for a patch that should otherwise be close to NFC. |
llvm/unittests/Transforms/Utils/LocalTest.cpp | ||
---|---|---|
590–591 | Per this comment, you should just delete the test. |
Copy/pasting my comment from https://reviews.llvm.org/rG1536e299e63d7788f38117b0212ca50eb76d7a3b#1217141 (I didn't see this code review because this commit didn't have the "Differential Revision" line)
Chrome is seeing a regression where the build size increased for Android and Fuchsia (https://crbug.com/1454531) - see the attached files.
Repro steps:
$ opt -passes=inline before-inline.S
The diff before and after this patch contains the following extra instructions:
while.cond.i.i.preheader.i.i: ; preds = %_ZNSt4__Cr6vectorIPN4base5ValueENS_9allocatorIS3_EEE4backEv.exit254.i, %_ZNSt4__Cr6vectorIPN4base5ValueENS_9allocatorIS3_EEE4backEv.exit242.i, %_ZNSt4__Cr6vectorIPN4base5ValueENS_9allocatorIS3_EEE4backEv.exit.i %cmp.not.i.i.i.i.i.i.i = icmp eq ptr %add.ptr.i.i, null br i1 %cmp.not.i.i.i.i.i.i.i, label %cond.false.i.i.i.i.i.i.i, label %_ZNSt4__Cr6vectorIPN4base5ValueENS_9allocatorIS3_EEE8pop_backEv.exit.i, !prof !4, !llvm.loop !5 cond.false.i.i.i.i.i.i.i: ; preds = %while.cond.i.i.preheader.i.i call void (ptr, ...) @_ZNSt4__Cr22__libcpp_verbose_abortEPKcz(ptr noundef nonnull @.str.10, ptr noundef nonnull @.str.11, i32 noundef 65, ptr noundef nonnull @.str.17, ptr noundef nonnull @.str.18) #29 unreachable
this was reverted due to causing size regressions, then relanded due to objections in https://reviews.llvm.org/rG464dcab8a6c823c9cb462bf4107797b8173de088 and the chain of reverts being longer than I expected. IIUC this was part of a forward fix for https://github.com/llvm/llvm-project/issues/63316, it would have been nice to get ToT back to a green state (but perhaps I'm missing some context on why reverting was hard, because more dependent commits?) to prevent this sort of revert of a forward fix reintroducing a regression.
also linking the phab review from the landed commit is helpful for provenance tracking
I'm looking into the inliner size regression caused by this now to fix forward
from what I can tell, the binary size increase seems to be due to instsimplify in the inliner respecting null_pointer_is_valid more, which is actually a bug fix
Another example of how null_pointer_is_valid is a kind of broken design. Can you add a test for this?
too much indent