Adjust warnings from target_kind.cc messages to debug level

[leandron]

This change moves recently introduced warning messages on target_kind.cc to be shown only in debug mode. The reason is because anytime we want to iterate over the list of targets they will be shown, making it overly verbose, e.g. in tvmc.

$ tvmc --version
[12:30:02] (long path)/src/target/target_kind.cc:217: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[12:30:02] (long path)/src/target/target_kind.cc:231: Unable to detect ROCm version, assuming >= 3.5
[12:30:02] (long path)/src/target/target_kind.cc:217: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[12:30:02] (long path)/src/target/target_kind.cc:231: Unable to detect ROCm version, assuming >= 3.5
0.9.dev0
...

cc @junrushao1994 @Leo-arm @gromero for reviews

[junrushao]

Thanks @leandron for bringing it up! The error message is only supposed to appear when user doesn’t supply arch information, and it could not be detected in our local environment- which means either the local environment is not set up properly, or it’s cross compilation without a clear target arch. Either case looks suspicious, and thus we think it’s necessary to provide error message explicitly.

Would you like to elaborate when the warning looks unnecessarily verbose? Is it in the CI environment?

[leandron]

Thanks @leandron for bringing it up! The error message is only supposed to appear when user doesn’t supply arch information, and it could not be detected in our local environment- which means either the local environment is not set up properly, or it’s cross compilation without a clear target arch. Either case looks suspicious, and thus we think it’s necessary to provide error message explicitly.

Would you like to elaborate when the warning looks unnecessarily verbose? Is it in the CI environment?

Sure, if you see the example I provide in the initial message, it is expected that some machines won’t have a Rocm and/or cuda version - they are optional dependencies anyway.

For those machines, the user will always see those warning messages, even when, for example, they would only want to target CPU with LLVM. This is what I meant by it being overly verbose, from the user point of view.

Perhaps we could make it more specific on when those messages are displayed, so that users see them when they are relevant in the context. I don’t have any proposal to solve that, but moving them to debug will make both the API and tvmc usage more clean.

[junrushao]

Thank you @leandron for the explanation!

Sure, if you see the example I provide in the initial message, it is expected that some machines won’t have a Rocm and/or cuda version - they are optional dependencies anyway.
For those machines, the user will always see those warning messages, even when, for example, they would only want to target CPU with LLVM. This is what I meant by it being overly verbose, from the user point of view.

Yeah I agree. Those dependencies like cuda or rocm are optional, and creating cuda/rocm targets probably means cross-compilation - in this case, not giving specific arch version looks like a bit fishy :-) And I agree that likely users just want to generate code for CPU with LLVM.

I'm 100% supportive of improve warning messages for TVMC and the overall TVM stack, and probably I don't have all the context, so might ask some really dumb questions - Why do these warning messages pop up even if users are not doing anything wrong? Is that because does tvmc --version constructs some dummy targets?

Thanks a lot!

[leandron]

Why do these warning messages pop up even if users are not doing anything wrong? Is that because does tvmc --version constructs some dummy targets?

Yes, there are some dumb targets being created, as a way to collect the arguments for each target.

tvm/python/tvm/driver/tvmc/target.py

Lines 47 to 57 in 515fc88

	def generate_target_args(parser):
	"""Walks through the TargetKind registry and generates arguments for each Target's options"""
	parser.add_argument(
	"--target",
	help="compilation target as plain string, inline JSON or path to a JSON file",
	required=True,
	)
	for target_kind in _valid_target_kinds():
	target = Target(target_kind)
	_generate_target_kind_args(parser, target.kind)

Any idea on how to solve the usability issue when creating these dummy targets?

[junrushao]

Aha I got it now. Thanks @leandron for the explanation!

The problem could go away if we do not create dummy Targets in TVMC if users don't specify them explicitly, and to make this happen, we could improve the implementation of the API ListTargetKindOptions:

tvm/src/target/target_kind.cc

Lines 52 to 58 in f32042f

	Map<String, String> TargetKindRegEntry::ListTargetKindOptions(const TargetKind& target_kind) {
	Map<String, String> options;
	for (const auto& kv : target_kind->key2vtype_) {
	options.Set(kv.first, kv.second.type_key);
	}
	return options;
	}

Right now it takes a TargetKind object and returns its key2vtype_ member. And to construct a TargetKind object, TVMC has to create dummy Targets and then extract its kind field.

tvm/python/tvm/driver/tvmc/target.py

Line 56 in 515fc88

_generate_target_kind_args(parser, target.kind)

Alternatively, it's possible to avoid doing so by wrapping it with a method that takes a string:

Map<String, String> ListTargetKindOptions(const String& target_kind_name) {
  return TargetKindRegEntry::ListTargetKindOptions(TargetKind::Get(target_kind_name).value());
}

In TVMC, we could pass in the target_kind_name as a string and get the information we want from the wrapper method above

[junrushao]

Hey what do you think of my proposal? It could completely avoid creating dummy targets in TVMC and preserve the warning message :-)

[u99127]

From a user perspective if you want to try it out very quickly and for the interest of being explicit, these just show up from using tlcpack-nightly from https://tlcpack.ai ..

[junrushao]

@u99127 Yep those warnings are annoying and that’s exactly we need to avoid. With my proposal (avoid creating dummy Target objects), these warnings won’t pop up

[junrushao]

Would you guys mind if I take over and implement my proposed approach to avoid creating dummy objects that lead to messy warnings?

[leandron]

Would you guys mind if I take over and implement my proposed approach to avoid creating dummy objects that lead to messy warnings?

Hi @junrushao1994, sorry I didn’t reply, as I got some other things to finish this week. In case you have some time and want to follow the approach you suggested, I’m fine with it, otherwise I’ll look into it when I get some time. Thanks for the help and for offering to sort this out!!

[junrushao]

@leandron Thanks! Submitted a follow-up PR #9662

[leandron]

Closing in favour of #9662