[code metadata] Allowing multiple metadata instances on an instruction?

[tlively]

The current code metadata (aka code annotations) documentation says,

funcannotations entries must appear in order of increasing idx, and duplicate idx values are not allowed. codeannotation entries must appear in order of increasing funcpos, and duplicate funcpos values are not allowed.

Since duplicate funcpos values are not allowed, it is not possible to attach multiple metadata instances to the same instruction. But it seems potentially useful to allow multiple metadata instances on a single instruction, for example to mark a branch as being likely or unlikely and also to mark it for instrumentation. There doesn't seem to be much downside to this since metadata is not semantically meaningful; in the worst case, contradictory metadata could just be ignored.

Should we update the text to only disallow decreasing funcpos values and allow duplicates?

cc @yuri91

[carlopi]

My understanding is that medatada.code instances reside each on its own section, so there the only problem left is whether a given type of metadata (eg. branch_hint or instrumentation or something else) would benefit from the possibility of attaching more than one byte string to a given instruction (= no limits on different types/kinds of metadata conflicting). Now within a given section & a given instruction it's possible to specify an arbitrary byte-string, so given a proper scheme it should be possible to encode anything. Do you see value in multiple hints then? Single hint guarantee means the parsing code (both engines & tools that transform Wasm) will possibly be simpler (even by just removing the question of what to do with potentially contradictory metadata).

[tlively]

Ah right, I hadn't thought about separate types of metadata having different sections. And yeah, a single metadata kind can handle any useful repetition in its own inner format. Thanks!