[PATCH] D149659: [AArch64][NFC] Refactor the tail-folding option
David Sherwood via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed May 10 06:14:08 PDT 2023
david-arm marked 2 inline comments as done.
david-arm added inline comments.
================
Comment at: llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp:49
+ uint8_t getBits(uint8_t DefaultBits) const {
+ if (!TailFoldTypes.size())
+ return DefaultBits;
----------------
sdesmalen wrote:
> I'm still not entirely happy with the concept of having to re-parse the full string every time this information is queried, but if that only happens very irregularly, I guess the overhead is only minimal.
>
> Just as a suggestion, one thing you could do is to parse the string for the `reductions/recurrences/reverse` early on and store that in a EnableBits + DisableBits mask, and have this separate from parsing of `simple/disabled/all/default`. Then, at the point of querying the tail folding options, you can do something like:
>
> uint8_t InitialBits = ... // either all zero, all ones, or SimpleBits or DefaultBits (queried from the target)
> Bits = (InitialBits | EnableBits) ^ DisableBits;
>
> It does mean that it would not be allowed to have a string such as `reductions+default`, because `default/all/disabled/simple` all need to come before the other toggle on/off options. Also, it might make make sense to also make it illegal to write `disabled+simple+all` because only one of those options should be set.
>
> This way the syntax would become:
> (disabled|all|default|simple)[+(reductions|recurrences|reverse|noreductions|norecurrences|noreverse)]*
I've tried to implement your suggestion as best I can!
================
Comment at: llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp:3533
- return (TailFoldingKindLoc & Required) == Required;
+ return TailFoldingOptionLoc.satisfies(ST->getSVETailFoldingDefaultOpts(),
+ Required);
----------------
sdesmalen wrote:
> I find this interface a little confusing and wonder if instead you can make `TailFoldingOptionLoc` a `std::string`, and then do:
>
> TailFoldingOption Opt(TailFoldingOptionLoc, ST->getSVETailFoldingDefaultOpts());
> return Opt.satisfies(Required);
>
> What do you think?
Now that we no longer parse the string each time, I'm not sure if it still makes sense to refactor this way? I could in theory create a small, new wrapper class with a different name just so I can pass in the option, but wasn't sure if it was worth the extra code?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D149659/new/
https://reviews.llvm.org/D149659
More information about the llvm-commits
mailing list