This is an archive of the discontinued LLVM Phabricator instance.

InstSimplify: Require instruction be parented
ClosedPublic

Authored by arsenm on May 23 2023, 1:42 PM.

Details

Summary

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).

Diff Detail

Event Timeline

arsenm created this revision.May 23 2023, 1:42 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2023, 1:42 PM
arsenm requested review of this revision.May 23 2023, 1:42 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2023, 1:42 PM
Herald added a subscriber: wdng. · View Herald Transcript
nikic added a comment.May 23 2023, 1:59 PM

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.)

arsenm updated this revision to Diff 525098.May 24 2023, 3:44 AM
arsenm marked 2 inline comments as done.

Documentation updates

I assume you plan to followup with a change that removes no longer needed checks from InstSimplify?

Yes

nikic added inline comments.May 24 2023, 5:23 AM
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.

arsenm updated this revision to Diff 527397.Jun 1 2023, 6:44 AM
arsenm marked 3 inline comments as done.

Try to preserve order

nikic added inline comments.Jun 1 2023, 6:51 AM
llvm/unittests/Transforms/Utils/LocalTest.cpp
590–591

Per this comment, you should just delete the test.

arsenm updated this revision to Diff 527979.Jun 2 2023, 2:30 PM
arsenm marked an inline comment as done.

Delete test

nikic accepted this revision.Jun 2 2023, 2:43 PM

LGTM

This revision is now accepted and ready to land.Jun 2 2023, 2:43 PM
ayzhao added a subscriber: ayzhao.Jun 16 2023, 11:29 AM

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

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?