This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Fix warnings due to SelectionDAG::getSplatSourceVector
ClosedPublic

Authored by david-arm on Apr 29 2020, 5:56 AM.

Details

Summary

I have fixed several places in getSplatSourceVector and isSplatValue
to work correctly with scalable vectors. I added new support for
the ISD::SPLAT_VECTOR DAG node as one of the obvious cases we can
support with scalable vectors. In other places I have tried to do
the sensible thing, such as bail out for vector types we don't yet
support or don't intend to support.

It's not possible to add IR test cases to cover these changes, since
they are currently only ever exercised on certain targets, e.g.
only X86 targets use the result of getSplatSourceVector. I've
assumed that X86 tests already exist to test these code paths for
fixed vectors. However, I have added some AArch64 unit tests that
test the specific functions I have changed.

Diff Detail

Event Timeline

david-arm created this revision.Apr 29 2020, 5:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 29 2020, 5:56 AM

Hi @david-arm ,

I think you could tests some of these methods of SelectionDAG directly like it has been done in llvm/unittest/CodeGen/AArch64SelectionDAGTest.cpp.

You can reuse the infrastructure in there to create the DAG instance, and from there build the values you want to test for the methods you have modified.

Francesco

OK @fpetrogalli I'll take a look!

david-arm updated this revision to Diff 261442.May 1 2020, 1:57 AM
david-arm edited the summary of this revision. (Show Details)

Hi @david-arm ,

thanks for adding the unit tests!

I have added few comments, most are repetitive...

You'll notice I am asking what DemandedElts and UndefElts references are for, and to add a comment in the code to explain. I think that while reviewing the code I understood what they are for (yes, I started from the tests, not from the implementation), but I still think that it would be good to expand the doxygen docs with their description.

Have a good weekend!

Francesco

llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
2279–2281

While we are looking at this function, let's not miss the opportunity to expand the docs here and explain what demanded elts and undef elts are! :)

2287–2288

Given that DemandedElts seems to make sense only for fixed size vectors, I think you should move this after the if (VT.isScalableVector()) return false; on line 2310, to make sure that all the code related to fixed size is run all together after the generic code of the switch.

Also, given that DemendedElts seem to make no sense for scalable vectors, I wonder if it is worth adding an assertion here along the lines of

assert((!VF.isScalable() || !DemandedElts) && "No access to arbitrary lanes at compile time for scalable vectors");
2391

This seems also a good candidate to unit test, at least for the three cases you have modified?

llvm/unittests/CodeGen/AArch64SelectionDAGTest.cpp
202

The tests would benefit of a couple of lines of comment explaining what you are testing...

210

Please add a comment to all constant parameters with the name of the parameters. Here and in the rest of the tests you have added.

211

Avoid auto when the type is not explicit in the RHS.

213

EXPECT_TRUE(DAG->isSplatValue(Op, false))

217

Similarly, use EXPECT_FALSE

220

EXPECT_TRUE

Question: what does DemandedElts = APInt(16, 3); changes from the invocation of isSplatValue at line 217 to modify its answer? A comment in the code would be much appreciated! :)
Background: I have no idea what DemandedElts mean, and why (16, 3) would change the previous answer. What would (33, 1) do?

234–235

Please don't use auto here.

239

EXPECT_TRUE

243

EXPECT_FALSE

246

EXPECT_TRUE

258

Don't use auto here.

260

EXPECT_TRUE

264

EXPECT_TRUE. I am too lazy to mark the remaining, and to do the reasonable thing to remove the previous one and add a generic comment to the review. :) Please fix all uses of expect with booleans.

266

Yeah, so, why do you always use APInt(16, 3)? Can you vary those values?

282–283

Don't use auto.

285

Don't use auto.

david-arm marked 13 inline comments as done.May 4 2020, 12:05 AM
david-arm added inline comments.
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
2279–2281

Hi Francesco, DemandedElts and UndefElts are used widely throughout the code base for many similarly named functions in both CodeGen and IR, so I don't think it makes sense to go into huge detail for these few functions alone. However, I can certainly update the comments for the functions I've changed and explain how DemandedElts and UndefElts are meaningless for scalable vectors.

2287–2288

I deliberately wanted the "if (!VT.isScalableVector() && !DemandedElts)" check at the start because there is no point doing any further work for fixed width vectors if the caller does not care about any of the elements.

2287–2288

With regards to adding an assert, you raise a good point. However, adding that assert will break my unit tests too so I would have to fix those up. Also, there is precedence in this area - see https://reviews.llvm.org/D79053, where asserts were not added for scalable vectors in similar cases. I'm not sure on this one - I'll have a think about it.

2391

Sure, I'd forgotten to test this. Sigh, writing unit tests is way more time consuming than the code changes themselves. :)

llvm/unittests/CodeGen/AArch64SelectionDAGTest.cpp
202

Fair point! I'll add comments.

210

Sure I can add a comment, but I'm not sure what value it would add because the value of the constant is irrevelant. Just a convenient way to get a splat that's all. I can say exactly that if you think that's useful?

211

See my respone to the last 'auto' comment.

234–235

See my respone to the last 'auto' comment.

258

See my respone to the last 'auto' comment.

264

OK sure, seems reasonable.

266

I didn't really see the need to vary the values to be honest. I waasn't sure what value it would add to the tests.

282–283

See my respone to the last 'auto' comment.

285

Hi Francesco, I use 'auto' here because the rest of the tests in this file does. I personally believe it is more important to follow the convention of the existing file, so if possible I'd like to leave these in.

david-arm marked an inline comment as done.May 4 2020, 1:29 AM
david-arm added inline comments.
llvm/unittests/CodeGen/AArch64SelectionDAGTest.cpp
285

Hi again, so I'm not sure what the LLVM coding standards are in this case - whether convention in an existing file takes priority or avoiding the use of "auto" takes priority. Sander also mentioned that it's probably more important to avoid 'auto' in new functions even in a file where it is used everywhere.

david-arm updated this revision to Diff 261807.May 4 2020, 7:14 AM
fpetrogalli accepted this revision.May 4 2020, 2:13 PM

Hi @david-arm ,

thank you for addressing (almost) all comments. Please notice that my reading of the coding standards would require to name at least the boolean parameters in a call. OK, maybe the getters of llvm::Vector are widely used an so adding comments to name them is not very important, but I think it would be important for things like DAG->isSplatValue(Op, false). I accepted the patch but please consider adding such comments before submitting.

Last request: for future reference, may I ask you to mark the comments you have addressed as done? It is quite easy to loose track of them otherwise.

Cheers!

Francesco

llvm/unittests/CodeGen/AArch64SelectionDAGTest.cpp
210

For the record, I didn't come up with this idea myself: https://llvm.org/docs/CodingStandards.html#comment-formatting

Admittedly, I might have pushed it a bit when I say "all parameters", but the text in the link seems to hint that bool constant should be named with a comment.

To me, the following change provides essential information that is worth having.

auto VecVT = EVT::getVectorVT(Context, IntVT, /*NumElements=/16, /*IsScalable=*/false);
285
This revision is now accepted and ready to land.May 4 2020, 2:13 PM
This revision was automatically updated to reflect the committed changes.