Actually, Armv8-A and Armv8-R profiles (both 64 bit, Armv8-M only T32 ) support CLZ/CLS as A64 base instructions.
Armv8-R, see D1-48 (CLZ unchanged): https://developer.arm.com/documentation/ddi0568/a-c/?lang=en
Armv8-A, see C6.2.58 :https://developer.arm.com/documentation/ddi0487/ja/?lang=en

ID_ISAR0_EL1, AArch32 Instruction Set Attribute Register 0
BitCount, bits [7:4]
Indicates the implemented Bit Counting instructions. Defined values are:
          0b0000 None implemented.
          0b0001 Adds CLZ.
All other values are reserved.
In Armv8-A, the only permitted value is 0b0001.

Armv8-M, see D1.2.129 https://developer.arm.com/documentation/ddi0553/latest/

// HaveMainExt()
// =============
// Check whether the Main Extension is implemented.
boolean HaveMainExt();

CLZ

if !HaveMainExt() then UNDEFINED;
if Rm != Rm2 then UNPREDICTABLE;
d = UInt(Rd); m = UInt(Rm); m2 = UInt(Rm2);
if d IN {13,15} || m IN {13,15} || m2 IN {13,15} then UNPREDICTABLE;

C2.4.37

ID_ISAR0, Instruction Set Attribute Register 0

BitCount, bits [7:4]
Bit count. Indicates the supported bit count instructions.
The possible values of this field are:
         0b0001
         CLZ supported.
All other values are reserved.
This field reads as 0b0001.

so it looks like it might be safe to use this instruction. Also, I see that in libkernel.h there is flsl, what do you think to use it instead of arm64_highest_set_bit?

You should definitely use flsl(). It will be emitted as a CLZ instruction, if appropriate. Just beware that the function is 1-indexed, and a return value of zero means "not set".

When will logical_imm be false?

I want to find a simpler way to express this, and eliminate the helper function (it is only used once).

I looked at the MoveWidePreferred pseudocode [1], what do you think of this? (I am unsure if this is the correct operation for immN:imms)

[1] https://developer.arm.com/documentation/ddi0596/2020-12/Shared-Pseudocode/AArch64-Instrs?lang=en#impl-aarch64.MoveWidePreferred.4

Suggested shorter name

Suggested shorter name

I hesitate at the strcmp, but I am not sure if there is any better way to do this.

In this patch I added definitions only for case when logical_imm is true and I did function according to pseudocode aarch64/instrs/integer/bitmasks/DecodeBitMasks https://developer.arm.com/documentation/ddi0596/2020-12/Shared-Pseudocode/AArch64-Instrs?lang=en

For the next patches I plan to reuse this function and use logical_imm as false. There are basic patterns (SBFM, BFM, UBFM) that have OP <RD>, <RN>, #<immr>, #<imms> and aliases with evaluation like this:

BFC <Wd>, #<lsb>, #<width>

... 
R = UInt(immr);
(wmask, tmask) = DecodeBitMasks(N, imms, immr, FALSE);

is equivalent to

BFM <Wd>, WZR, #(-<lsb> MOD 32), #(<width>-1)

ref:
https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/BFM--Bitfield-Move-?lang=en

Removed helper function and simplified.

immN:imms is combination of values, for example:
immN is 1 bit value
imms is 6 bits value

So, if we have immN = 0b1 and imms = 0b001010, result will be:

immN:imms = 0b1001010

I checked Arm architecture reference manual, there are decode group/instruction page, (see C4.1 A64 instruction set encoding, https://developer.arm.com/documentation/ddi0487/latest/)

There is group - "Data Processing -- Immediate" (see C4.1.92 Data Processing -- Immediate)

This patch adds support for Logical (immediate), see instruction page - C4.1.92.5 Logical (immediate).
I suppose that we will use only logical immediate instructions for TYPE_05, so we can identify ORR instruction by extracting opc field - 01 instead of strcmp, what do you think?

{F97924285}

It is definitely preferable to extract and check the extra field from the instruction.