This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Select MIMG instructions manually in SITargetLowering

Authored by nhaehnle on Jun 11 2018, 5:50 AM.



Having TableGen patterns for image intrinsics is hitting limitations:
for D16 we already have to manually pre-lower the packing of data
values, and we will have to do the same for A16 eventually.

Since there is already some custom C++ code anyway, it is arguably easier
to just do everything in C++, now that we can use the beefed-up generic
tables backend of TableGen to provide all the required metadata and map
intrinsics to corresponding opcodes. With this approach, all image
intrinsic lowering happens in SITargetLowering::lowerImage. That code is
dense due to all the cases that it handles, but it should still be easier
to follow than what we had before, by virtue of it all being done in a
single location, and by virtue of not relying on the TableGen pattern
magic that very few people really understand.

This means that we will have MachineSDNodes with MIMG instructions
during DAG combining, but that seems alright: previously we had
intrinsic nodes instead, but those are similarly opaque to the generic
CodeGen infrastructure, and the final pattern matching just did a 1:1
translation to machine instructions anyway. If anything, the fact that
we now merge the address words into a vector before DAG combine should
be an advantage.

Change-Id: I417f26bd88f54ce9781c1668acc01f3f99774de6

Diff Detail


Event Timeline

nhaehnle created this revision.Jun 11 2018, 5:50 AM
rampitec accepted this revision.Jun 11 2018, 10:34 AM

Thank you! I am in favor of this change even despite what we have discussed today. If we eventually want to create target ISD nodes it could be done on top of it and separately, but currently I see no such need.
A separate note: SIISelLowering.cpp has really overgrown, it is already about 8000 lines. Maybe we shall consider splitting it into separate pieces as a separate change. Like this stuff is something like SIImageLowering.cpp.

This revision is now accepted and ready to land.Jun 11 2018, 10:34 AM
arsenm added inline comments.Jun 11 2018, 12:43 PM
4505–4506 ↗(On Diff #150726)

.ScalarType() == s16

4507 ↗(On Diff #150726)

I think we already have a hasD16 feature?

4527 ↗(On Diff #150726)

I'm going to be committing that patch soon so might as well just wait for that

4550 ↗(On Diff #150726)

Isn't this always the case?

4565–4566 ↗(On Diff #150726)


nhaehnle updated this revision to Diff 151332.Jun 14 2018, 5:36 AM
nhaehnle marked 3 inline comments as done.

Address review comments

nhaehnle added inline comments.Jun 14 2018, 5:37 AM
4505–4506 ↗(On Diff #150726)


4507 ↗(On Diff #150726)

I don't see one. There's a hasUnpackedD16VMem(), but that just says whether D16 is unpacked or packed (if it exists).

FWIW, I'm not a fan of having explicit feature flags for features that are already clearly delineated by hardware generations, which is the case for D16.

4527 ↗(On Diff #150726)

Sure, will do. There's a few more changes to come anyway, and I want to submit them all at once to reduce merge conflicts with our internal branches.

4550 ↗(On Diff #150726)

No. getlod and getresinfo don't access memory and are INTRINSIC_WO_CHAIN.

4565–4566 ↗(On Diff #150726)

Good point, changed. It doesn't seem like any downstream users care...

This revision was automatically updated to reflect the committed changes.