[clang] [llvm] [CodeGen][KCFI] Allow setting type hash from xxHash64 to FNV-1a (PR #167254)
Jordan Rupprecht via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 4 08:39:43 PST 2025
================
@@ -11,17 +11,18 @@
//===----------------------------------------------------------------------===//
#include "llvm/Transforms/Utils/ModuleUtils.h"
-#include "llvm/Analysis/VectorUtils.h"
#include "llvm/ADT/SmallString.h"
+#include "llvm/Analysis/VectorUtils.h"
#include "llvm/IR/DerivedTypes.h"
#include "llvm/IR/Function.h"
#include "llvm/IR/IRBuilder.h"
#include "llvm/IR/MDBuilder.h"
#include "llvm/IR/Module.h"
#include "llvm/Support/Casting.h"
+#include "llvm/Support/Hash.h"
#include "llvm/Support/MD5.h"
#include "llvm/Support/raw_ostream.h"
-#include "llvm/Support/xxhash.h"
+#include "llvm/Transforms/Instrumentation/KCFI.h"
----------------
rupprecht wrote:
Not a build config per se, but I was fixing the bazel build and needed to add a dep from TransformUtils -> Instrumentation, and bazel error'd out due to the cycle.
Bazel itself is in the peripheral tier, so don't worry about keeping it green. But library layering issues are something that should be avoided (https://llvm.org/docs/CodingStandards.html#library-layering), and the bazel configs are much more sensitive to layering issues than cmake configs are. This is one of the few cases where a bazel-specific failure can point to a real issue even if bazel failures are categorically not blocking.
https://github.com/llvm/llvm-project/pull/167254
More information about the llvm-commits
mailing list