This is an archive of the discontinued LLVM Phabricator instance.

[DAG][AArch64] Fix truncated vscale constant types
ClosedPublic

Authored by dmgreen on Jul 18 2023, 10:20 AM.

Details

Summary

It appears that vscale values truncated to i1 causes mismatches in the constant types when created in getNode. https://godbolt.org/z/TaaTo86ne.

Diff Detail

Event Timeline

dmgreen created this revision.Jul 18 2023, 10:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2023, 10:20 AM
dmgreen requested review of this revision.Jul 18 2023, 10:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2023, 10:20 AM
dmgreen updated this revision to Diff 541699.Jul 18 2023, 1:18 PM

Just trunc the constant, as opposed to being opinionated about the sign.

sdesmalen added inline comments.Jul 19 2023, 12:36 AM
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
5752–5753

SelectionDAG::getVScale does the right thing by truncating the APInt value, but it only does so after the assert:

assert(MulImm.getSignificantBits() <= VT.getSizeInBits() &&
          "Immediate does not fit VT");

which fails because for MulImm=1, MulImm.getSignificantBits() results in 2. This happens because it adds the sign bit, which for a 1-bit value is nonsensical. I think the better thing to do is to fix the assert itself.

I have confirmed this fixes the assertion failure seen on the SVE VLA bots.

Allen added a subscriber: Allen.Jul 19 2023, 2:11 AM
dmgreen updated this revision to Diff 541922.Jul 19 2023, 2:50 AM

Thanks for checking!

This version adds a special case for i1 to the assert.

dmgreen added inline comments.Jul 19 2023, 2:52 AM
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
5752–5753

I'm not sure it wouldn't be better for getVScale to only accept APInt of the correct bitwidth, to be more precise. I couldn't see any other code that looked like the APInt and the VT could be a mismatch.

The new version just adds an override for i1 to the assert. Let me know what you think.

sdesmalen added inline comments.Jul 19 2023, 5:48 AM
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
1944–1945

I guess this still needs an additional check that for MVT::i1 the immediate fits, i.e. ... || (VT == MVT::i1 && MulImm <= 1) ?

cseo added a subscriber: cseo.Jul 19 2023, 8:10 AM
Matt added a subscriber: Matt.Jul 19 2023, 10:30 AM

I was thinking about it, and I think it would be better to not be sloppy about the APInt passed to getVScale. Similar to existing methods in DAG like getConstant, we should be asserting that the size of the APInt and the type match. Otherwise it should be up to the caller to make them match in a way that is appropriate.

It appears from looking through the calls to getVScale that the version in getNode when truncating the value is the only one where they can be a mismatch.

dmgreen updated this revision to Diff 542168.Jul 19 2023, 1:28 PM

Assert the sizes of the type and APInt match in getVScale.

Thanks for fixing this @dmgreen !

Any chance to land this soon? We (folks working on SVE/SSVE/SME support in MLIR) rely heavily on clang-aarch64-sve-vla that's currently failing.

sdesmalen accepted this revision.Jul 20 2023, 12:01 AM

I was thinking about it, and I think it would be better to not be sloppy about the APInt passed to getVScale. Similar to existing methods in DAG like getConstant, we should be asserting that the size of the APInt and the type match. Otherwise it should be up to the caller to make them match in a way that is appropriate.

It appears from looking through the calls to getVScale that the version in getNode when truncating the value is the only one where they can be a mismatch.

That makes sense. I thought there would have been more instances that needed fixing, but glad to see that wasn't the case.

This revision is now accepted and ready to land.Jul 20 2023, 12:01 AM

Thanks. I'll commit this now, just after my machine has finished rerunning the tests. Hopefully I didn't miss any cases for getVScale.

This revision was landed with ongoing or failed builds.Jul 20 2023, 1:12 AM
This revision was automatically updated to reflect the committed changes.