I just noticed two issues in the current target specification:
P1. Whether to sort the attribute values by default or not
We currently use an array to store target attributes (if it has multiple values) and preserve its order when serializing a target to a string. However, it seems unnecessary for most attributes. For example, the following two targets would have different serialized strings:
t1 = tvm.target.create('cuda -libs=cublas,cudnn') t2 = tvm.target.create('cuda -libs=cudnn,cublas')
To me, these two targets are exactly the same, and we should have a unified string if two targets are functional equivalent.
Another example is the target of Rasp4:
tvm.target.create('llvm ... -mattr=+neon,fp-armv8,thumb-mode')
IUUC, the order of
mattr should not be preserved.
Of course, we do have exceptions like
keys which order has to be preserved, but
keys is already a standalone property of target, so we don’t have to worry about it.
IMHO, it would make more sense to make all attributes values unordered sets by default, and sort them when serialization to guarantee the target string is deterministic. For the ordered attribute values, we may allow developers to specify it as ordered.
P2. Semantic of matching two targets
When applying the history best log or the TopHub fallback log from AutoTVM/Ansor, it first matches the target model (e.g.,
1080ti) and then keys (e.g.,
cuda). It means we may get a record with target
llvm -mcpu=skylake-avx512 when querying records with target
Another follow-up issue is that if we use the target
cuda -libs=cudnn and TopHub has a record of
conv2d_nchw.cuda for the target workload. In this case, we will match the record on the TopHub and use it to build the model instead of cuDNN. This is not an expected behavior. One solution is also putting a record of
conv2d_cudnn to the TopHub so that the op strategy will compare their latencies and select the better one, although this may not be user’s intention, neither.