This is an archive of the discontinued LLVM Phabricator instance.

Scalarizer: Support scalarizing intrinsics
ClosedPublic

Authored by arsenm on Jun 24 2016, 2:44 PM.

Details

Diff Detail

Event Timeline

arsenm updated this revision to Diff 61845.Jun 24 2016, 2:44 PM
arsenm retitled this revision from to Scalarizer: Support scalarizing intrinsics.
arsenm updated this object.
arsenm added a reviewer: rsandifo.
arsenm added a subscriber: llvm-commits.
arsenm added a reviewer: mehdi_amini.
mehdi_amini added inline comments.Jul 13 2016, 6:33 PM
lib/Transforms/Scalar/Scalarizer.cpp
110

It is not clear to me what is this doing?
(Why do you need the CI member for instance)

Looks like you mimic'd struct BinarySplitter, but simplifications make it moot.

412

Document the function

431

Is this dead code?

437

This seems to assume that every vector operand must have the same number of elements as the returned type?

439

Would this loop be equivalent to:

for (auto &Operand : I->operands()) {
  if (!Operand.getType()->isVectorTy())
    ScalarOperands[I] = CI.getOperand(I);
  else {
    Scattered[I] = scatter(&CI, CI.getOperand(I));
    assert(Scattered[I].size() == NumElems && "mismatched call operands");
  }
}

I'm not sure about hasVectorInstrinsicScalarOpd though...

445

I think you could pass the initial size to the ctor.
It may even be better to call reserve() on ScalarCallOps though as the next thing is clearing it.
I'd probably use reserve on Res as well and use push_back in the loop below.

462

A comment above the loop can be appreciated.

arsenm updated this revision to Diff 64630.Jul 19 2016, 7:09 PM
arsenm marked 2 inline comments as done.

Address comments

lib/Transforms/Scalar/Scalarizer.cpp
437

This is true for all of the current intrinsics, I can add a comment

439

Yes, the hasVectorInstrinsicScalarOpd is why this is over the index

445

That's what I originally did, but the scalar operand complicated using push_back, so now it always sets the appropriate index. I would expect such an intrinsic to fail isTriviallyScalarizable since a different vector size probably should be treated like the scalar operand index

mehdi_amini accepted this revision.Jul 19 2016, 9:16 PM
mehdi_amini edited edge metadata.

LGTM, with two comments

lib/Transforms/Scalar/Scalarizer.cpp
437

The comment seems truncated (and too long for a single line), clang-format?

I'm surprised no intrinsic are breaking this, is it an assumption baked everywhere in the optimizer?
It makes the code fragile to future intrinsics.

439

Why using this hasVectorInstrinsicScalarOpd()?
I'm not even sure to understand its implementation by the way, it says Identifies if the intrinsic has a scalar operand but only check the intrinsic id for a specific list. That sounds quite fragile? The type seems much more likely to be "the source of truth".

This revision is now accepted and ready to land.Jul 19 2016, 9:16 PM
arsenm added inline comments.Jul 20 2016, 8:42 AM
lib/Transforms/Scalar/Scalarizer.cpp
437

I don't think it's that surprising. There's no obvious scalarizaton/vectorization for something like that. Not many places really care about the general types of intrinsics besides the vectorizers.

439

It also checks the operand index. This is just the existing mechanism, I guess it would also work to check the type

arsenm added inline comments.Jul 25 2016, 1:02 PM
lib/Transforms/Scalar/Scalarizer.cpp
439

The use below needs it because it doesn't check the actual value, it only knows the index when picking between the vector and scalar args

arsenm closed this revision.Jul 25 2016, 1:10 PM

r276681