This is an archive of the discontinued LLVM Phabricator instance.

[ARM][GISel] PR35965 Constrain RegClasses of nested instructions built from Dst Pattern
ClosedPublic

Authored by rtereshin on Jan 26 2018, 1:23 AM.

Details

Summary

Apparently, we missed on constraining register classes of VReg-operands of all the instructions
built from a destination pattern but the root (top-level) one. The issue exposed itself
while selecting G_FPTOSI for armv7: the corresponding pattern generates VTOSIZS wrapped
into COPY_TO_REGCLASS, so top-level COPY_TO_REGCLASS gets properly constrained,
while nested VTOSIZS (or rather its destination virtual register to be exact) does not.

Fixing this by issuing GIR_ConstrainSelectedInstOperands for every nested GIR_BuildMI.

https://bugs.llvm.org/show_bug.cgi?id=35965
rdar://problem/36886530

Patch by Roman Tereshin

Diff Detail

Event Timeline

rtereshin created this revision.Jan 26 2018, 1:23 AM
rtereshin retitled this revision from [ARM][GISel] PR35965 Constrain RegClasses of nested instructions built from Dst Patter to [ARM][GISel] PR35965 Constrain RegClasses of nested instructions built from Dst Pattern.Jan 26 2018, 1:26 AM
rovka accepted this revision.Jan 26 2018, 3:29 AM

LGTM, thanks!

This revision is now accepted and ready to land.Jan 26 2018, 3:29 AM

LGTM with a nit. Thanks for looking into this.

lib/CodeGen/GlobalISel/Utils.cpp
56–59

This is a bit more general than I'd like. I agree that TargetOpcodes like COPY shouldn't fail, but I think GenericOpcodes and target specific instructions should. Could you assert(!isPreISelGenericOpcode() && !isTargetSpecificOpcode()) inside this if-statement?

dsanders accepted this revision.Jan 26 2018, 10:25 AM
rtereshin added inline comments.Jan 26 2018, 10:31 AM
lib/CodeGen/GlobalISel/Utils.cpp
56–59

Sure! That's just what I needed to know: how to describe in a generic way all the instructions like COPY here, huge thanks!

rtereshin marked 2 inline comments as done.Jan 26 2018, 11:33 AM

@dsanders Hi Daniel, could you please commit this for me?

dsanders edited the summary of this revision. (Show Details)Jan 26 2018, 3:54 PM
qcolombet added inline comments.Jan 26 2018, 5:15 PM
lib/CodeGen/GlobalISel/Utils.cpp
56–59

I believe this part should go in separately.
This is not related to the TableGen change.

62

I believe bailing out won't be enough generally speaking, unless we expect the users of this method to do the right thing for PHIs and COPY.

E.g., by bailing out on COPYs we could end up with unconstrained VRegs in cases like this:
v1 = COPY v1 won't get constrained
v2 = COPY v1
<-- v2 will be constrained by its users

Usually that means we have useless COPYs though.

test/CodeGen/ARM/GlobalISel/arm-select-fptosi-pr35965.mir
2

Could you use something more descriptive than prxxx in the file name or just drop it?

Reference the PR in the comment here though.

rtereshin added inline comments.Jan 26 2018, 5:50 PM
lib/CodeGen/GlobalISel/Utils.cpp
56–59

It is related in a sense that the TableGen change would break GlobalISel for some of the targets w/o this change.

62

True, but this patch doesn't make this problem either better or worse. Maybe solve it in a different patch, but commit this one so we don't block ARM folks?

test/CodeGen/ARM/GlobalISel/arm-select-fptosi-pr35965.mir
2

Sure! I looked around, saw names like this, and thought it's a standard practice to follow =) Glad to know that it's not.

rtereshin updated this revision to Diff 131675.Jan 26 2018, 6:46 PM
rtereshin marked 2 inline comments as done.
rtereshin updated this revision to Diff 131678.Jan 26 2018, 7:17 PM
rtereshin marked 2 inline comments as done.
rtereshin added inline comments.Jan 29 2018, 11:22 AM
lib/CodeGen/GlobalISel/Utils.cpp
56–59

Looks like if we put it in a separate patch it will go w/o a test case, as to catch the problem we need to call constrainSelectedInstRegOperands on a copy, and that never currently happens as:

  1. selectImpl currently doesn't support COPY at all, and every target handles them before calling selectImpl
  2. If COPY is introduced by a destination pattern nothing constrains it as we weren't constraining nested instructions before the tablegen part of this patch.
  3. (2) never caused a problem as existing targets (apparently) don't have patterns like this.

So I don't quite see an a reasonably simple way to come up with a test for this that actually fails before the fix w/o introducing a fake testing target.

In other words, this part of this patch can't have a test case w/o the tablegen part, but the tablegen part can't go in w/o this as it will cause existing tests to fail.

qcolombet accepted this revision.Jan 29 2018, 12:02 PM

Got a chat with Roman off-line and turns out the problem I mentioned is worked around by everything single target, so indeed no test cases!
LGTM then

This revision was automatically updated to reflect the committed changes.