[llvm] Implements PGOBBAddrMap in Object and ObjectYAML with tests [1/5] (PR #71750)

James Henderson via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 22 01:10:53 PST 2023


================
@@ -645,11 +647,39 @@ ELFFile<ELFT>::toMappedAddr(uint64_t VAddr, WarningHandler WarnHandler) const {
   return base() + Offset;
 }
 
-template <class ELFT>
-Expected<std::vector<BBAddrMap>>
-ELFFile<ELFT>::decodeBBAddrMap(const Elf_Shdr &Sec,
-                               const Elf_Shdr *RelaSec) const {
-  bool IsRelocatable = getHeader().e_type == ELF::ET_REL;
+// Helper to extract and decode the next ULEB128 value as unsigned int.
+// Returns zero and sets ULEBSizeErr if the ULEB128 value exceeds the unsigned
+// int limit.
+// Also returns zero if ULEBSizeErr is already in an error state.
+// ULEBSizeErr is an out variable if an error occurs.
+template <typename IntTy>
+static IntTy readULEB128As(DataExtractor &Data, DataExtractor::Cursor &Cur,
+                           Error &ULEBSizeErr) {
+  static_assert(std::is_unsigned_v<IntTy> &&
+                    (std::numeric_limits<IntTy>::radix == 2),
+                "only use unsigned radix 2");
----------------
jh7370 wrote:

I'm not sure if you're doing the same thing I imagined. I played around with your code, and the template signature just becomes:
```
template <typename IntTy,
          typename = std::enable_if_t<std::is_unsigned_v<IntTy> &&
                                      (std::numeric_limits<IntTy>::radix == 2)>>
```
Which doesn't seem weirdly formatted to me and doesn't use `bool_constant`? I think `enable_if` (or any other SFINAE approach) is the more canonical way in C++ of preventing use of a template function rather than a `static_assert`.

But anyway, is the `radix` part actually needed? What case would it suppress that you think is potentially going to happen? What would be the issue if the function were to be used with such an integer type (if the static_assert/enable_if weren't present)?

https://github.com/llvm/llvm-project/pull/71750


More information about the llvm-commits mailing list