Ga1axy0 commented on code in PR #19877:
URL: https://github.com/apache/tvm/pull/19877#discussion_r3464248447
##########
src/target/llvm/llvm_instance.cc:
##########
@@ -199,15 +277,31 @@ LLVMTargetInfo::LLVMTargetInfo(LLVMInstance& instance,
if (triple_.empty() || triple_ == "default") {
triple_ = llvm::sys::getDefaultTargetTriple();
}
+ bool has_explicit_mcpu = target.Get("mcpu").has_value();
cpu_ =
target.Get("mcpu").value_or(ffi::String(defaults::cpu)).as_or_throw<ffi::String>();
+ bool has_explicit_mattr = false;
if (const auto& v = (target.Get("mattr"))
.value_or(nullptr)
.as_or_throw<ffi::Optional<ffi::Array<ffi::String>>>()) {
+ has_explicit_mattr = true;
for (const ffi::String& s : v.value()) {
attrs_.push_back(s);
}
}
+
+ llvm::Triple target_triple(triple_);
+ auto arch = target_triple.getArch();
+ llvm::Triple host_triple(llvm::sys::getDefaultTargetTriple());
+ if (!has_explicit_mattr && !has_explicit_mcpu && arch ==
host_triple.getArch() &&
+ target_triple.getOS() == host_triple.getOS() &&
Review Comment:
Thanks for the clarification. I agree that adding RISC-V-specific host
probing logic in this generic LLVM path is not the right direction.
The original motivation is still valid, but it should probably be handled
through LLVM or a more explicit TVM target mechanism instead. I will close this
PR for now and reconsider the design.
Thanks for the review.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
