This is an archive of the discontinued LLVM Phabricator instance.

Handling of TRAP during isel
AbandonedPublic

Authored by jonpa on Jun 13 2017, 6:00 AM.

Details

Reviewers
uweigand
efriedma
Summary

The one thing that keeps the SystemZ backend from enabling expensive checks, is the issue with the trap instruction. See https://bugs.llvm.org/show_bug.cgi?id=33047.

Current discussion is:

  • It looks like targets are split over whether they consider their "trap" a terminator; x86, AArch64, and NVPTX don't, but ARM, MIPS, PPC, and SystemZ do. We should probably try to be consistent here.
  • If the isTerminator is flag is used, how should isel handle instructions after it? Note that this is only an issue at -O0.

I did a quick experiment to see what would happen if I just added isTerminator on all targets trap instructions, and then handled TRAP during selection DAG building. This however caused a lot of regression test failures, so this is not a working patch right now.

Diff Detail

Event Timeline

jonpa created this revision.Jun 13 2017, 6:00 AM
RKSimon edited reviewers, added: efriedma; removed: eli.friedman.Jun 13 2017, 7:01 AM
RKSimon added a subscriber: RKSimon.
efriedma edited edge metadata.Jun 14 2017, 2:39 PM

Needs testcase. (-verify-machineinstrs will run the verifier even if it's off by default for your target.)

Some targets special-case Intrinsic::trap in FastISel; need separate testcases for that (and maybe fixes).

I'm not sure I agree with the approach; just because it doesn't return doesn't mean you have to mark it a terminator. A call to the C library function abort() is also a "terminator", but we don't treat it as one because it's just simpler to treat it like a regular call.

Some targets special-case Intrinsic::trap in FastISel; need separate testcases for that (and maybe fixes).

I'm not sure I agree with the approach; just because it doesn't return doesn't mean you have to mark it a terminator. A call to the C library function abort() is also a "terminator", but we don't treat it as one because it's just simpler to treat it like a regular call.

Does that mean that it is enough to have the hasCtrlDep / hasSideEffects flag, so that it will never be removed rescheduled / removed? What happens in this test case on SystemZ is that any returning argument COPYs will be incorrectly be placed before it, but maybe that doesn't matter in the case of a trapping instruction (?).

Is there any opinion from any other target maintainer on this?

jonpa abandoned this revision.Jun 22 2017, 5:11 AM

Due to the many test failures on the other targets, it seems much simpler to remove the barrier and terminator flags on the trap instructions. This seems to work fine for SystemZ without any code change on benchmarks.