There seems to be an issue with how LLVM handles local IDs, where labels with explicit local ID names are not accounted for when incrementing the local ID counter.
A label with the explicit name "0" is treated as a named value and the local ID 0 may be assigned to subsequent basic blocks or other values. In contrast, a local variable with the explicit name "%0" is treated as an unnamed value, and assigned the local ID 0.
While the issue exist upstream, for now we will resolve the issue by printing the labels of unnamed basic blocks in comments, following the convention used by Clang. We will try to engage with LLVM developers, and ask whether this is an explicit design decision, or an unintended implementation detail. Hopefully the discussions will turn out fruitfully and the seeming inconsistency may be fixed upstream, or we may receive a more in-depth understanding of the reasons behind this seeming inconsistency. In either way, its a win.
There seems to be an issue with how LLVM handles local IDs, where labels with explicit local ID names are not accounted for when incrementing the local ID counter.
A label with the explicit name "0" is treated as a named value and the local ID 0 may be assigned to subsequent basic blocks or other values. In contrast, a local variable with the explicit name "%0" is treated as an unnamed value, and assigned the local ID 0.
While the issue exist upstream, for now we will resolve the issue by printing the labels of unnamed basic blocks in comments, following the convention used by Clang. We will try to engage with LLVM developers, and ask whether this is an explicit design decision, or an unintended implementation detail. Hopefully the discussions will turn out fruitfully and the seeming inconsistency may be fixed upstream, or we may receive a more in-depth understanding of the reasons behind this seeming inconsistency. In either way, its a win.