[PATCH] D139627: clang/X86: Don't emit "min-legal-vector-width"="0"
Matt Arsenault via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 8 11:51:55 PST 2022
arsenm added a comment.
In D139627#3981475 <https://reviews.llvm.org/D139627#3981475>, @pengfei wrote:
> The use of `min-legal-vector-width` doesn't look great to me either. I'm more than glad if we can remove it totally without any user perceivable affects.
> I cannot agree with this change because it neither eliminates the clutter (but makes it even worse [1]) nor is NFC to end user.
> I think we used `UINT32_MAX` just to be compatible with BCs that generated before introduing the attribute. This change definitely breaks the compatibility.
What I'm getting is this is only a performance hint, and definitively doesn't matter for ABI purposes. Bitcode backwards performance compatibility is not important. That would also be recovered by having a proper attribute propagation done as an optimization.
I think all of clang's handling of this should be purged, except for the part where it's passing through the user attribute.
> Placing a `"min-legal-vector-width" = "512"` doesn't make any sense either. For one thing, we cannot place the attribute in pre-built BC files, for another `512` is the current max vector suppoted on X86, we cannot guarantee no `1024`, `2048` etc. in future and we cannot change it too once compiled into BC files.
It's a test for specific behavior, with a specific configuration that exists today. It doesn't matter what this would be in the future for larger testcases
> [1] `"min-legal-vector-width" = "0"` was clear to indicate there are only scalar operations.
It's not remotely clear what this means
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D139627/new/
https://reviews.llvm.org/D139627
More information about the llvm-commits
mailing list