On Mon, 28 Aug 2023 at 10:07, Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
>
> While here make sure labels are unique.
I'll take a look at the other changes later, but this one I reacted
to: please don't do this.
It's a disaster. It makes people make up random numbers, and then
pointlessly change them if the code moves around etc.
Numeric labels should make sense *locally*. The way to disambiguate
them is to have each use just have "f" and 'b" to distinguish whether
it refers forward or backwards.
And then just keep the numbering sensible in a *local* scope, because
the "file global" scope is just such a complete pain when you
pointlessly change the numbering just because some entirely unrelated
non-local thing changed.
And yes, you can see some confusion in the existing code where it uses
0/1/2/3, and that was because I just didn't consistently put the
exception table entries closer, and then moved things around. So the
current code isn't entirely consistent either, but let's once and for
all make it clear that the sequential numbering is wrong, wrong,
wrong.
The numeric labels should not use sequential numbers, they should use
purely "locally sensible" numbers., and the exception handling should
similarly be as locally sensible as possible.
And if you use complicated numbering, please make the numbering be
some sane visually sensible grouping with commentary (ie that unrolled
'movq' loop case, or for an even nastier case see commit 034ff37d3407:
"x86: rewrite '__copy_user_nocache' function").
So if anything, the existing 2/3 labels in that file should be made
into 0/1. Because I've seen way too many of the "pointlessly renumber
lines just to sort them and make them unique".
I used to do that when I was twelve years old because of nasty BASIC
line numbering.
I'm a big boy now, all grown up, and I don't want to still live in a
world where we renumber lines because we added some code in the
middle.
The alternative, of course, is to use actual proper named labels. And
for "real assembly code" that is obviously always the right solution.
But for exception table entries or for random assembler macros, that's
actually horrendous.
The numeric labels literally *exist* to avoid the uniqueness
requirements, exactly because for things like assembler macros, you
want to be able to re-use the same (local) label in a macro expansion
multiple times.
So trying to make numeric labels unique is literally missing the
entire *point* of them.
Linus
