https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113686
--- Comment #2 from H. Peter Anvin <hpa at zytor dot com> --- The intermediate alignment for lui is known, so if an object is known to fit *entirely* within its natural alignment then it can be safely CSE'd, but this is typically not the case with structures or arrays. It would be nice to fix this in the architecture (as a new standard extension). Unfortunately, due to the decision to allocate 3/4 of the instruction encoding space to 16-bit instructions only 3 completely reserved 5-bit opcodes remain - and that is only what is currently in the ISA document. Adding "auipc1" and "lui1" would consume two of those (they would most naturally fall at op = 1X10011) There are some less desirable options, like reclaiming part of the encoding space for longer instructions (requiring another 1 bit in the prefix for long instructions would provide the additional two encodings); on RV32 *only* the RV64 encoding space op = 0X11011 could be used, but I doubt it would be much appreciated to have this capability on RV32 and not RV64. (Not to mention hacks like only having part of the register space accessible, which wouldn't necessarily be horrendous, though, as these instructions would belong in some pretty fixed patterns.) One could also say that auipc1 would be "good enough" (combined with PC-relative relocations for TLS, at least for the TE model) and would still be valuable enough to occupy a full opcode. (Obviously, the idea would be that these instructions really are pseudo-instructions carrying one more immediate bit, and that the linker would apply those bits using "HI21" relocations.) I think this is something where the ISA architects could really use to hear from you compiler developers; since I'm not really familiar with where the pain points in the compiler lie, it is hard for me to speak authoritatively.
