Skip to content

[RISCV] Implement encoding for CI-type instructions in terms of its Shift. NFCI#1269

Draft
Jonathon Penix (jonathonpenix) wants to merge 2 commits into
qualcomm:mainfrom
jonathonpenix:pr/ci_type_imm_shift
Draft

[RISCV] Implement encoding for CI-type instructions in terms of its Shift. NFCI#1269
Jonathon Penix (jonathonpenix) wants to merge 2 commits into
qualcomm:mainfrom
jonathonpenix:pr/ci_type_imm_shift

Conversation

@jonathonpenix

Copy link
Copy Markdown
Contributor

A follow-up patch will add a new internal relocation to handle c.li.
Currently, encodeCI looks for the immediate in the higher bits of Result
(bits 17 and 16:12) which makes sense for c.lui handling but not really for
c.li (where we want to look at bits 5 and 4:0).

I don't think this would work as-is for some of the other CI-type instructions
if they ever need to be handled so it isn't entirely generic. But, this should
be sufficient for supporting both c.li and c.lui. I also think this is
marginally simpler/more straightforward than creating a separate EncTy_* or
checking the instruction type, etc. so I went this route for now.

Note isValidRVCLUIType is now in a (more) broken state as I didn't update the
call to encodeCI. As far as I can tell, this code is already dead/broken (it
ultimately calls extractRVCImmediate which itself has a typo (exractBits)
so has never been compile-able as far as I can tell. Not sure if we want to fix
this up or just remove it, so I'm leaving it be for the purposes of this patch.

======

Stacked on #1268

This code should be dead as `R_RISCV_RVC_LUI` is an internal relocation to help
with relaxation and the only place we emit this relocation already checks that
the immediate is non-zero.

Cleaning this up is also helpful as a follow up patch will introduce a new
internal relocation for `c.li` (for handling GOT load relaxations). The
existing code is incorrect for that case, and cleaning this up will let us
handle these two consistently (and more consistently with other instruction
types).

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
…Shift`. NFCI

A follow-up patch will add a new internal relocation to handle `c.li`.
Currently, `encodeCI` looks for the immediate in the higher bits of `Result`
(bits 17 and 16:12) which makes sense for `c.lui` handling but not really for
`c.li` (where we want to look at bits 5 and 4:0).

I don't think this would work as-is for some of the other CI-type instructions
if they ever need to be handled so it isn't entirely generic. But, this should
be sufficient for supporting both `c.li` and `c.lui`. I also think this is
marginally simpler/more straightforward than creating a separate `EncTy_*` or
checking the instruction type, etc. so I went this route for now.

Note `isValidRVCLUIType` is now in a (more) broken state as I didn't update the
call to `encodeCI`. As far as I can tell, this code is already dead/broken (it
ultimately calls `extractRVCImmediate` which itself has a typo (`exractBits`)
so has never been compile-able as far as I can tell. Not sure if we want to fix
this up or just remove it, so I'm leaving it be for the purposes of this patch.

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>

@lenary Sam Elliott (lenary) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Instruction types are a bit annoying in the C extension, potentially less relevant, but this seems the best approach.

@jonathonpenix Jonathon Penix (jonathonpenix) marked this pull request as draft June 26, 2026 04:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants