This is an archive of the discontinued LLVM Phabricator instance.

[LoongArch] Add privilege instructions definition
ClosedPublic

Authored by SixWeining on May 2 2022, 11:59 PM.

Details

Summary

These instructions are added by following the `LoongArch Reference
Manual Volume 1: Basic Architecture Version 1.00`.

Depends on D124825

Diff Detail

Event Timeline

SixWeining created this revision.May 2 2022, 11:59 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 2 2022, 11:59 PM
SixWeining requested review of this revision.May 2 2022, 11:59 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 2 2022, 11:59 PM

A polite ping. Thanks.

xen0n added a comment.May 10 2022, 8:29 PM

I'm a bit busy doing other projects (and day job), but thanks for the patch; coverage should be pretty complete after this, and finally the meaty parts are coming!

llvm/lib/Target/LoongArch/LoongArchInstrInfo.td
555

nit: "Privileged" -- please fix all other occurrences of "privilege instruction(s)" everywhere else.

558–567

So we don't treat csrrdand csrwr as special-cases of csrxchg, sharing the same opcode, only with different behavior? i.e., warn if csrxchg's rj is r0 or r1, but don't outright fail, and make csrrd and csrwr syntactic sugars. This way csrxchg's special semantics are left to consumers to handle, which I think would be acceptable. The benefit is that csrxchg remains as a "direct" representation of underlying machine code, without everyone having to deal with overlapping opcodes for only 3 exceedingly rare insns. No sane developer would regalloc r0 or r1 for an atomic CSR access after reading the manual, and if they really wanted to write a zero without using a temp register, a runtime error during testing is more-or-less the same as a compile-time error.

The current approach *may* be inconvenient, as I could envision some existing tools generating assembly code for llvm-mc, but unable to represent completely overlapping opcodes; these tools would only be able to emit plain csrxchg under the current implementation, as putting r0 or r1 into its rj slot would be illegal. I might be wrong here, so I'd welcome additional input.

llvm/test/MC/LoongArch/Basic/Privilege/invalid.s
13

same as above: "privileged". Change wherever necessary for fixing this.

SixWeining added inline comments.May 11 2022, 1:12 AM
llvm/lib/Target/LoongArch/LoongArchInstrInfo.td
558–567

Sorry I don't understand what you mean.

Do you mean the assembler can take csrxchg rd, r0, num as csrrd rd, and csrxchg rd, r1, num as csrwr?
Do you mean only need to define csrxchg and 2 alias (csrrd csrrw) for it? Just like nop is the alias of andi r0, r0, 0?

xen0n added inline comments.May 12 2022, 1:32 AM
llvm/lib/Target/LoongArch/LoongArchInstrInfo.td
558–567

Sorry I don't understand what you mean.

Do you mean the assembler can take csrxchg rd, r0, num as csrrd rd, and csrxchg rd, r1, num as csrwr?
Do you mean only need to define csrxchg and 2 alias (csrrd csrrw) for it? Just like nop is the alias of andi r0, r0, 0?

Yes, exactly this.

SixWeining added inline comments.May 12 2022, 4:51 AM
llvm/lib/Target/LoongArch/LoongArchInstrInfo.td
558–567

OK, I see. Thanks for the suggestion.

I think this is more or less a modification request to the published LoongArch ISA manual. Until then let's keep the current approach which is loyal to the manual directly.

xen0n added a comment.May 12 2022, 6:46 PM

Now that my concern is more-or-less addressed, let's see what others think...

llvm/lib/Target/LoongArch/LoongArchInstrInfo.td
558–567

Looking at the manual more closely, it actually didn't mention the requirement to treat csrrd/csrwr as distinct from csrxchg; only in the Appendix B (instruction encodings) you can see the distinction. Again here it's arguably obvious the three insns are sharing the same opcode prefix (thus implying csrrd/csrwr are rational abuses of csrxchg encoding).

For now I agree with you though; on one hand I didn't check the binutils behavior, on the other hand a more direct syntax (and other amendments to the manual) would be better for a future iteration, both for projects (binutils/llvm/etc.) and something like a v1.10 or even v2.00 manual.

xen0n accepted this revision.May 12 2022, 6:46 PM

forgot to mark approval

This revision is now accepted and ready to land.May 12 2022, 6:46 PM
This revision was automatically updated to reflect the committed changes.