This is an archive of the discontinued LLVM Phabricator instance.

[RISCV][NFC] Refactor RISC-V vector intrinsic utils.
ClosedPublic

Authored by kito-cheng on Apr 30 2022, 11:59 PM.

Details

Summary

This patch is preparation for D111617, use class/struct/enum rather than char/StringRef to present internal information as possible, that provide more compact way to store those info and also easier to serialize/deserialize.

And also that improve readability of the code, e.g. "v" vs TypeProfile::Vector.

Diff Detail

Event Timeline

kito-cheng created this revision.Apr 30 2022, 11:59 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 30 2022, 11:59 PM
kito-cheng requested review of this revision.Apr 30 2022, 11:59 PM

Changes:

  • Extract more utils functions to RISCVVIntrinsicUtils

Thanks for refactoring!

clang/include/clang/Support/RISCVVIntrinsicUtils.h
55

I think vector is not a primitive type in common sense, is it?
why Widening2XVector, Widening4XVector, Widening8XVector and MaskVector is not part of VectorTypeModifier?

Sorry, I'm confused and maybe forget something.

85

I think we need to update the comment in riscv_vector.td to sync the word "TypeProfile", I feel the new word TypeProfile is similar to modifier or prototype, is it?

The C/C++ prototype of the builtin is defined by the Prototype attribute.
Prototype is a non-empty sequence of type transformers, the first of which
is the return type of the builtin and the rest are the parameters of the
builtin, in order. For instance if Prototype is "wvv" and TypeRange is "si"
a first builtin will have type

we call it modifier or prototype is because those words are coming from clang intrinsic definition and other target.

https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Builtins.def#L52
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/arm_sve.td#L58

personally I think consistent naming maybe better than creating a new word, what do you think?

BTW, I think having this new class is really good idea for refactoring!

90

If we allow parameter could uint8_t, why other constructors not follow the same rule?

97

What's purpose of this function, translate TypeProfile to the Proto string?

249

additional space

clang/lib/Support/RISCVVIntrinsicUtils.cpp
767

In riscv_vector.td is said smaller or larger, I feel little confusing here when it call LagerThan. maybe have more comment like The result of modified type should be smaller than giving type ?

kito-cheng marked 3 inline comments as done.

Changes:

  • Address @khchen's comment.
  • Use new hash scheme for cache the result of computeType.
clang/include/clang/Support/RISCVVIntrinsicUtils.h
55

I think vector is not a primitive type in common sense, is it?

It's called primitive type transformer on the comment[1], so that's why I use PrimitiveType here, but I admit that's kind of confusing, maybe BaseTypeModifier?

Widening2XVector, Widening4XVector, Widening8XVector and MaskVector is not part of VectorTypeModifier?

Good point, Moved to VectorTypeModifier!

[1] https://github.com/llvm/llvm-project/blob/main/clang/lib/Support/RISCVVIntrinsicUtils.cpp#L366

85

Renamed to PrototypeDescriptor, that should be better I guess :)

90

Keep only two version of constructor, one for all uint8_t and one for all enum.

All enum one used for checking type safe as possilbe.
And uint8_t version used for low-level construct (used in https://reviews.llvm.org/D111617)

97

Used for caching the RVVType, but I realized we could use integer(uint64_t) as hash value, use new hash scheme in new version.

khchen accepted this revision.May 13 2022, 8:23 AM

Thanks Kito. This all LGTM except some warnings need to fix.

clang/lib/Support/RISCVVIntrinsicUtils.cpp
377

so we also need to update this comment as base type transformer?

706

Don’t use default labels in fully covered switches over enumerations
please remove default in RISCVVIntrinsicUtils.cpp:624, RISCVVIntrinsicUtils.cpp:717 and RISCVVIntrinsicUtils.cpp:793.

931
clang/lib/Support/RISCVVIntrinsicUtils.cpp:962:10: warning: moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
  return std::move(PrototypeDescriptors);
         ^
clang/lib/Support/RISCVVIntrinsicUtils.cpp:962:10: note: remove std::move call here
  return std::move(PrototypeDescriptors);
This revision is now accepted and ready to land.May 13 2022, 8:23 AM
This revision was automatically updated to reflect the committed changes.
kadircet added inline comments.
clang/lib/Support/RISCVVIntrinsicUtils.cpp
33

these were previously owned by RVVEmitter, hence we would have one instance per invocation. After this move, and the follow up patch that introduced lazy lookup, now we actually have a race condition in tools that can perform concurrent AST builds (e.g. any tool, like clang-tidy, that might have multiple Semas alive because they're being executed with all-TUs executor, or clangd when the user opens multiple files).

Rather than having these caches as global singletons (or static local variables as things have evolved since this patch), can we:

  • make them owned by RISCVIntrinsicManagerImpl (while getting rid of the cache for TableGen purposes completely, isn't it already generating the full header, why does it need a cache?)? that way we would get one instance per Sema and prevent above mentioned race conditions
  • add some locks to synchronise access to these caches.

This has been triggering crashes in clangd for a long while now (tracking it back to this issue wasn't easy, sorry for the delay)

Hi @kito-cheng, can you please let us know if you're working on a fix here (and whether it seems to be close)? otherwise i am planning to revert this and consequent changes, as it's clearly introducing data races.

Hi @kito-cheng, can you please let us know if you're working on a fix here (and whether it seems to be close)? otherwise i am planning to revert this and consequent changes, as it's clearly introducing data races.

FYI, dropping all the caching and pass-by-pointer logic in https://reviews.llvm.org/D138287

kito-cheng marked 2 inline comments as done.Nov 21 2022, 2:14 AM

@kadircet ooops, sorry for missing your comment, let me figure out how to fix that.

thanks Kito! not sure if you've noticed D138287, but if landing a solution
is going to take a long while here, i'd like to move forward with that
approach to make sure this doesn't stay in a broken state. so it'd be great
if you can give some updates/estimates about fixing this soon.