This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Fix ICE in SelectionDAG::computeKnownBits
ClosedPublic

Authored by scott.linder on Jul 19 2018, 3:45 PM.

Details

Summary

SelectionDAG::computeKnownBits asserts handling EXTRACT_SUBVECTOR when zero extending the demanded elements mask if it is already as long as the source vector.

One assumption with the fix is that it is valid for EXTRACT_SUBVECTOR to ask for the entire original vector, which appears valid from reading the code. The test is just for the absence of the assert, as there is nothing in the IR/DAG to check for.

Diff Detail

Event Timeline

scott.linder created this revision.Jul 19 2018, 3:45 PM

I think SelectionDAG::ComputeNumSignBits and TargetLowering::SimplifyDemandedVectorElts suffer from the same issue - can you deal with those as well ?

test/CodeGen/AMDGPU/extract-subvector-equal-length.ll
1

FileCheck ?

Addressed feedback; updated other places where DemandedElts is zero extended to the source vector width.

I do not have a FileCheck in the test because the passing condition is just for there to be no assert during CodeGen. There is nothing wrong with the IR/DAG/ISA at any point when the bug is or isn't present, so I don't know what to check for.

Any chance that you can add tests for SelectionDAG::ComputeNumSignBits and TargetLowering::SimplifyDemandedVectorElts ?

Addressed feedback; updated other places where DemandedElts is zero extended to the source vector width.

I do not have a FileCheck in the test because the passing condition is just for there to be no assert during CodeGen. There is nothing wrong with the IR/DAG/ISA at any point when the bug is or isn't present, so I don't know what to check for.

The operation ultimately produces something . In this case I would probably just use update_llc_checks

I can update the test with update_llc_checks, but I'm not sure about testing the other functions. This test case is a minimized version of a test which happened to trigger the assert; to test the others would it be reasonable to use unit tests instead of LLVM IR?

scott.linder added inline comments.Jul 24 2018, 9:25 AM
lib/CodeGen/SelectionDAG/TargetLowering.cpp
1488 ↗(On Diff #156508)

In writing tests for this version of the code in TargetLowering, I noticed that the condition here is actually more strict than in the equivalent code in SelectionDAG. In this function the subsequent zext can never assert. I still believe my original patch is correct, and I believe this condition can be relaxed to just ugt, but the fact that the code differs makes me wonder why.

Can someone who is more familiar with the code see a reason for the different condition?

I have updated the lit test with update_llc_test_checks, updated the condition in TargetLowering to allow for the case where DemandedElts is already wide enough, and added unittests for the cases which trigger the ICE in each function. This is still dependent on my assumptions about the exact semantics of EXTRACT_SUBVECTOR being correct.

I can update the test with update_llc_checks, but I'm not sure about testing the other functions. This test case is a minimized version of a test which happened to trigger the assert; to test the others would it be reasonable to use unit tests instead of LLVM IR?

I'm not sure it's possible with SelectionDAG. I don't think we have any other way

I noticed I had assumed AArch64 was available in the unittests, so I updated those to be skipped in the case where it isn't.

@arsenm what do you mean is impossible? These appear to be some of the first unittests for SelectionDAG, but I don't see how to test these cases without adding them. Even if there is a reason not to add them, I still can't add more IR tests for the remaining cases.

I feel guilty now, but it might make sense to keep just the original computeKnownBits fix you did in this patch, get that reviewed/committed so we can merge into 7.00 to fix PR38459. And move the other fixes/tests into a new patch?

That sounds fine to me; here is the original patch, with the updated test.

I've confirmed this still resolves https://bugs.llvm.org/show_bug.cgi?id=38459

RKSimon accepted this revision.Aug 13 2018, 10:23 AM

LGTM - cheers

This revision is now accepted and ready to land.Aug 13 2018, 10:23 AM
This revision was automatically updated to reflect the committed changes.