Add pseudoinstruction: sext.b, sext.h, zext.b, zext.h and zext.w

[kito-cheng]

Add sext.b, sext.h, zext.b, zext.h and zext.w, and mention sext.b and sext.h could be non pseudo instruction, the motivation is we already has sext.w now, and B ext also want to define more pseudo for sext or zext, so why not add to the baseline pseudo instruction, and let assembler pick best way to expand.

[kito-cheng]

@clairexen @aswaterman

[aswaterman]

Seems reasonable to me, to simplify some assembly programming. However, compilers should avoid avoid sext.[b|h] and zext.[h|w] when Zbb isn't present (though actually Zba can implement zext.w, too), since it can be more efficient to schedule the two shifts apart from each other.

[kito-cheng]

However, compilers should avoid avoid sext.[b|h] and zext.[h|w] when Zbb isn't present (though actually Zba can implement zext.w, too), since it can be more efficient to schedule the two shifts apart from each other.

Agree with that, generally compiler should avoid emit pseudo instruction, which will expand to more than one instructions...unless necessary like call or tail.

[jim-wilson]

Zba has zext.h also, so all of them are a single instruction with the B extension.

This creates work for binutils and llvm developers, and maybe FreeBSD also. We can handle the binutils work. Who does the llvm work? It would be nice to get an OK from the LLVM folks at least before committing this.

[kito-cheng]

@lenary @ebahapo

We can handle the binutils work. Who does the llvm work?

We have few LLVM developer now, and it should not too much effort I guess, maybe @topperc could help on that?

[kito-cheng]

Note: I didn't mention how pseudo expand with B-extension on purpose, since it still might change.

[topperc]

I agree it shouldn't be much effort in LLVM. I can help.

[kito-cheng]

@topperc thanks you take this :)

I guess just wait some another LLVM folks (maybe non-SiFive guys?) to ack this.

[lenary]

I don't have a fundamental problem with this, and would be happy to help review a patch :)

[lenary]

I do wonder if we want to say "at most two 32-bit instructions" or the like, in these docs? It's unclear to me what guarantees people coding with pseudo-instructions want - turning off relaxation and compressed instructions is needed even if you stick to non-pseduo-instructions and want predictable instruction sizes - presumably if you require predictable instruction sizes, it's also best to stay away from pseudo-instructions too.

[nick-knight]

From my perspective as an assembly programmer who uses pseudoinstructions, all I really want are clear descriptions of

• the different code sequences that the assembler may emit (vs. saying "myriad sequences"), and
• the different linker relaxations that may be subsequently applied (vs. saying "go read the ld source tree").

In terms of "guarantees", what I'm looking for is a guarantee that "(only) the following things may happen" to my assembly program. What isn't clear to me is whether these things should be considered implementation details --- thus belonging in assembler/linker documentation --- or part of the assembly language specification --- thus belonging here.

I completely understand that we are woefully understaffed w.r.t. documentation, I'm not asking anyone to do anything.

[lenary]

@kito-cheng fyi, I revise my offer to "review" a patch that implements this, I've got an LLVM patch mostly ready which I'll upload to phabricator and tag you as a reviewer for.

[kito-cheng]

Changes:

• Add more description about we might emit another code sequence when B extension is enabled, but not specify the code sequence at this moment, because it's not frozen yet.

[kito-cheng]

@lenary I saw the patch, thanks!

[kito-cheng]

@lenary Changes applied, thanks!

[lenary]

I just landed the LLVM implementation in https://github.com/llvm/llvm-project/commit/12406ade0625