| Issue |
108704
|
| Summary |
[clang] The VecLib bitfield in CodeGenOptions.def is too small for 9 different vector libraries
|
| Labels |
clang
|
| Assignees |
|
| Reporter |
pawosm-arm
|
The VecLib bitfield is defined in `clang/include/clang/Basic/CodeGenOptions.def` as such:
```
// Vector functions library to use.
ENUM_CODEGENOPT(VecLib, llvm::driver::VectorLibrary, 3, llvm::driver::VectorLibrary::NoLibrary)
```
When this bitfield had been introduced, there were not many of the Vector Libraries to choose. Now we have 9 of them, as defined in `Options.td`:
```
def fveclib : Joined<["-"], "fveclib=">, Group<f_Group>,
Visibility<[ClangOption, CC1Option, FlangOption, FC1Option]>,
HelpText<"Use the given vector functions library">,
Values<"Accelerate,libmvec,MASSV,SVML,SLEEF,Darwin_libsystem_m,ArmPL,AMDLIBM,none">,
NormalizedValuesScope<"llvm::driver::VectorLibrary">,
NormalizedValues<["Accelerate", "LIBMVEC", "MASSV", "SVML", "SLEEF",
"Darwin_libsystem_m", "ArmPL", "AMDLIBM", "NoLibrary"]>,
MarshallingInfoEnum<CodeGenOpts<"VecLib">, "NoLibrary">;
```
In effect, they are not encoded correclty resulting in mysterious cases of the lost vectorization opportunity.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
