Changing "backend: <foo>" labels on GitHub to not being backend specific?

I don’t know if usage of this tag is consistent across different targets, but my intuitive understanding of “backend: foo” is that it should be used related to that specific backend, but not necessarily any issue related to that target (e.g. target-specific Clang frontend issues, target-specific LLD issues and so on). Do people have that same understanding?

To me, “target: foo” more clearly applies to target-specific issues across any part of the LLVM project, and IMHO it would be more useful to have a clear label for this. Any thoughts?

Would you include LLDB, compiler-rt and llvm-libc issues in that, or just the “pure” toolchain? Then what about flang?

That’s a good question. target:foo might be too broad to my taste. E.g. target:aarch64 might include all issues appearing on aarch64 as well (e.g. host related things). Given that people watch particular tags, it might cause unwanted increase of notifications.

Yes, all of those things. For me personally, the advantage of being able to easily subscribe to anything RISC-V related would outweigh any disadvantage I think. But others may disagree.

Should that not be host:aarch64?

I can see the use for it, though from my perspective I don’t care at all about LLDB or libc, but I do care about LLVM, Clang and LLD (plus libc++ and libunwind). I guess one could argue that since there’s no one-size-fits-all approach here it’s better to broadcast it all (especially given most of the bugs will be LLVM and/or Clang that most people will care about) and let people filter in their inboxes as needed.

Exactly. But I think @asb’s suggestions would be to fold this into a generic catch-all aarch64 (or riscv) tag that one could use for everything specific to a particular platform.

That’s pretty much my argument. I also think the backend: foo tag get’s used for non-backend things a fair bit anyway, just inconsistently.

The motivating issue I had in mind was lld incorrectly emits region overflow errors when linker relaxation would prevent an overflow · Issue #62423 · llvm/llvm-project · GitHub - this rightfully doesn’t have the backend: riscv tag, but I certainly would have liked to have been subscribed to it, and I imagine most other subscribers to the backend: riscv tag would too. People may have different levels of interest in other LLVM sub-projects, but I think the traffic volume is so low it wouldn’t make a big difference if you get a subscribed to a few more issues than is ideal.