Open frantisekz opened 1 year ago
I can confirm this issue here. Enabling VC (-DIGC_BUILD__VC_ENABLED=ON) causes the reported compilation failiure for me.
Version 1.0.14062.11
is one of the lastest releases, which works for me with enabled VC.
@ConiKost If I understand it correctly, the failing functions are only for debugging, I was able to make it build with the following workaround:
--- a/IGC/VectorCompiler/lib/GenXCodeGen/GenXSimdCFConformance.cpp
+++ b/IGC/VectorCompiler/lib/GenXCodeGen/GenXSimdCFConformance.cpp
@@ -1867,11 +1867,13 @@ void GenXSimdCFConformance::ensureConformance() {
IID != GenXIntrinsic::genx_simdcf_unmask &&
IID != GenXIntrinsic::genx_simdcf_remask) {
EMValsStack.insert(*i);
+ #ifdef DEBUG_VERBOSE_ON
LLVM_DEBUG(if (auto *Inst = dyn_cast<Instruction>(i->getValue())) {
auto FuncName = Inst->getFunction()->getName();
dbgs() << "Entry EMVals " << FuncName << " - ";
i->getValue()->dump();
});
+ #endif
}
}
for (auto i = EMVals.begin(), e = EMVals.end(); i != e; ++i) {
@@ -1919,6 +1921,7 @@ void GenXSimdCFConformance::ensureConformance() {
// been identified in the early pass, unless passes in between have
// transformed the code in an unexpected way that has made the simd CF
// non-conformant. Give an error here if this has happened.
+ #ifdef DEBUG_VERBOSE_ON
if (!GotosToLower.empty()) {
dbgs() << "Not empty GotosToLower:";
for (auto *Dump : GotosToLower)
@@ -1929,6 +1932,7 @@ void GenXSimdCFConformance::ensureConformance() {
for (auto *Dump : JoinsToLower)
Dump->dump();
}
+ #endif
IGC_ASSERT_EXIT_MESSAGE(
GotosToLower.empty(),
"unexpected non-conformant SIMD CF in late SIMD CF conformance pass");
@@ -2460,8 +2464,10 @@ static bool checkAllUsesAreSelectOrWrRegion(Value *V) {
auto User2 = cast<Instruction>(ui2->getUser());
unsigned OpNum = ui2->getOperandNo();
++ui2;
+ #ifdef DEBUG_VERBOSE_ON
LLVM_DEBUG(dbgs() << "checkAllUsesAreSelectOrWrRegion: for user ";
User2->dump());
+ #endif
if (isa<SelectInst>(User2))
continue;
@@ -3006,12 +3012,14 @@ bool GenXSimdCFConformance::getConnectedVals(
}
} else {
if (!UsersToLower.empty()) {
+ #ifdef DEBUG_VERBOSE_ON
LLVM_DEBUG(dbgs() << "getConnectedVals: find bad users:\n";
for (auto &BadUser
: UsersToLower) {
dbgs() << " ";
BadUser.dump();
});
+ #endif
return false;
}
}
--
@frantisekz Yes, I can confirm. Patch fixes the error for me.
@frantisekz thanks a lot for reporting and triage! Will fix this issue as soon as possible. But it is better to use default llvm-debug defines:
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
If you build with a "Debug" llvm, then the llvm::Value::dump
symbol is available (in libLLVMCore, maybe?). But if you are using a production (Release) build of llvm, then it's not.
The culprit commit to GenXSimdCFConfrmance.cpp was 6db7f8779e86431dc46da4a31ca63f8664e78053 back in March, 2023:
+ if (auto *Inst = dyn_cast<Instruction>(i->getValue())) {
+ auto FuncName = Inst->getFunction()->getName();
+ LLVM_DEBUG(dbgs() << "Entry EMVals " << FuncName << " - ";
+ i->getValue()->dump());
+ }
Similarly, if you build intel-graphics-compiler with as Release (invoke cmake with -DCMAKE_BUILD_TYPE=Release), then the build should use -DNDEBUG and LLVM_DEBUG becomes a no-op. And that IS true (i.e., -DNDEBUG is used) for some of the compilation commands in the tree. But not for anything under GenXCodeGen. So that just looks like some cmake work to ensure -DNDEBUG gets passed in the GenXCodeGen compilation. I don't have a CMakeLists.txt patch at the moment.
For me, for the moment, I reverted to building Release 1.0.13463.18 - that was before the above commit.
Fix has been merged in https://github.com/intel/intel-graphics-compiler/commit/9be3363c1f9f97627566d88a56e6e612a74691b3 . Please re-check, because I can't reproduce bug locally.
@igorban-intel Thank you! :-) I can confirm, applying your patch solves the issue.
Fix has been merged in 9be3363 . Please re-check, because I can't reproduce bug locally.
That does not fix the problem that when building intel-graphics-compiler with -DCMAKE_BUILD_TYPE=Release, -DNDEBUG is not passed to compilation in GenXCodeGen/.
The above commit does remove the call to llvm::Value::dump (even when -DNDEBUG is not defined). So it does address the undefined reference.
But -NDEBUG should be passed to compilation when doing a Release build. -DNDEBUG has the effect of disabling LLVM_DEBUG (as intended and is documented in LLVM_DEBUG usage).
Granted that problem (-DNDEBUG should be passed to compilation when building for Release thus disabling LLVM_DEBUG) is a separate bug than the one posted in this issue. But it would have solved this issue.
Fix has been merged in 9be3363 . Please re-check, because I can't reproduce bug locally.
And to reproduce it locally, the recipe would have been to build intel-graphics-compiler (the version that called llvm::Value::dump) against a Release version of llvm - i.e., one where libLLVMCore does not define llvm::Value::dump (a Debug version of llvm defines that symbol).
llvm could also be built with -DLLVM_ENABLE_ASSERTIONS=ON or -DLLVM_ENABLE_DUMP to get llvm::Value::dump.
See also https://stackoverflow.com/a/46700512 for an alleged equivalent to using llvm::Value::dump() See also https://groups.google.com/g/llvm-dev/c/rO1zCNxET5U
Thanks @jhgit for your investigation - we will re-check builds to pass NDEBUG-option
@igorban-intel , How about
LLVM_DEBUG(
dbgs() << *Instr;
// OR
Instr->print(dbgs());
)
?
Somewhere between igc 1.0.13700.7 and 1.0.14896.8, the build regressed with (I can do a proper bisect if needed):
The relevant flags and params are:
And the configure is called with:
Used llvm version is 15.0.7, opencl-clang bc1d13ecc1c6f7aa5da3acf33165037d3fc5ed06, and vc fe92a377338258b725cfbd0a1bd49a9cf5e2864c .