AMD64 psABI says: "The pr_data field of each property contains a 4-byte unsigned integer." Thus we don't need to handle 8-byte pr_data.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Yes, there is a similar patch for the data size in https://reviews.llvm.org/D56080, which deal with the size in X86 llvm asmprint.
Looks correct, FTR ABI link is https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-draft.pdf.
Regarding the refactoring, in my opinion, the original code was simpler. I would leave it as is.
(at least refactoring change could be in a separate patch, if you want to do it)
For GNU_PROPERTY_X86_FEATURE_1_AND, there are only 2 bits. When people start implementing
GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_ISA_2_USED GNU_PROPERTY_X86_COMPAT_ISA_1_USED, this style will become better :)
There are different ways to do a refactoring here. For example, it could probably be:
auto DumpFlag = [](StringRef Name, uint64_t Flag, uint32_t &Val) { if (Val & Flag) { Val &= ~Flag; OS << Name; if (Val) OS << ", "; } }; DumpFlag("IBT", GNU_PROPERTY_X86_FEATURE_1_IBT, pr_data); DumpFlag("SHSTK", GNU_PROPERTY_X86_FEATURE_1_SHSTK, pr_data);
Which still looks simpler to me, but you or other people might disagree,
so probably it is better to discuss the refactoring in a different review.
My main point is that functional and refactoring changes
should not be mixed in the same patch.
Your approach looks great! Moved the refactoring part (I also have to implement GNU_PROPERTY_X86_FEATURE_2_{NEEDED,USED} to demonstrate the idea) to D58112