https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
--- Comment #12 from Peter Cordes <peter at cordes dot ca> --- (In reply to Jakub Jelinek from comment #10) > (In reply to Peter Cordes from comment #9) > > gcc already totally misses optimizations here where one string is a suffix > > of another. "mii" could just be a pointer to the 3rd byte of "sgmii", but > > we instead duplicate all the characters. That's where major savings are > > possible for this function. > > ?? That is the task for the linker SHF_MERGE|SHF_STRINGS handling. > Why should gcc duplicate that? Oops, right I was only looking at gcc's asm output, didn't check an actual linked binary. Will the linker currently catch a case like this? .LC_base: .LC2: .string "mii" .LC3: .string "gmii" table: .byte .LC2 - .LC_base, .LC3 - .LC_base and drop .string "mii" entirely + rewrite the table to .byte .LC3+1 - .LC_base, .LC3 - .LC_base (This discussion should probably be happening on bug 85585.) Sorry I don't know the actual mechanism by which gcc signals to the linker that it can / can't merge. I guess only in some sections? Because gcc couldn't allow it if was emitting an array like this, where dropping a string would change the offsets for later data and break offset calculations: const struct { char str[11]; } table[] = { {"mii"}, {"gmii"} };