Thanks @fhahn I've added a comment to regsEqual describing what it can be used for.

Friendly ping..

Merged k_ExactFPImm with k_FPImm.

Hi @olista01 , I just tried merging this change with k_FPImm and one of the problems I'm running into is with the '#0.0' and InstAliases.
For example in SVEInstrFormats.td, class sve_int_dup_imm:

InstAlias<"fmov $Zd, #0.0", (!cast<Instruction>(NAME # _S) ZPR32:$Zd, 0, 0), 1>;

The k_FPImm case works a little different.. Instead of it storing the APFloat value, it stores the (AArch64_AM) encoded FP imm value. If the value cannot be encoded, the parser throws an error. Also not all values can be encoded, such as '0.0', for which the parser (for k_FPImm) puts in a "#0.0" string literal into the parsed operands list. The two cases can be merged, but I think it may be better to do that in a separate patch as this will require some refactoring and changes to match e.g. the #0.0 case in existing FP instructions.

Removed some redundant test-cases for fmov alias that are already tested by test/MC/AArch64/SVE/fdup.s

I think the difference with other immediates that have a limited set, is that these immediates have a non-trivial parsing/decoding/printing. Rather than just allowing a given range of integer values the string is first parsed as FP value and then encoded as integer value between 0-255. And the opposite for the decode. I think it makes sense to test these cases individually, although I can see how doing this for the FMOV alias as well could be a bit excessive, so I'll reduce those.

In D47482#1118614, @fhahn wrote:

Looks good, but do the tests have to be that big? That makes it really hard to spot if the edge cases & aliases are handled properly. Can you reduce the size a bit?

Since the immediate encoding only allows for a limited set of 256 different floating-point immediates, I thought it would make sense to test each of them separately to make sure they are all correctly parsed, assembled and printed, since basically these are all the edge-cases. The negative tests are much smaller and test a few floating point values that cannot be encoded. I can easily reduce the tests, but I think these tests are valuable. What do you think?

In D47518#1116074, @javed.absar wrote:

Should the commit message be " Splat floating-point immediate value to SVE vector". Or may be i am wrong on this?

That sounds similar, but there is some distinction in that it uses predication. It is a predicated splat of an immediate value into the result vector with merging predication.
I used the word 'copy' instead of 'splat' since that is the name of the instruction. Splat would be more appropriate for D47482 .

Addressed nits and cleanup isSVEAddSubImm.

• Removed some brackets and updated the patch to reflect change in D47309.

• Some simplifications (such as getShiftedVal())
• Moved a change from patch D47310 (in isAddSubImm()) into this patch to resolve a failing test that would otherwise be solved by D47310, related to checking whether a value is a shifted value.

LGTM! Thanks for adding the negative tests and rationale.

In D46682#1094231, @javed.absar wrote:

I might be good to put commit-message/description.

In D46270#1083792, @samparker wrote:

The new instruction classes have a lot of overlap, I think it would be nicer to refactor them and pass more than asm string as an argument.

Hi Sam, there are two reasons I didn't merge these into the same instruction classes for this patch...
One is that we chose to structure the file by the encoding groups from the SVE specification and merge instruction classes only when they are in the same group (e.g. {z_fill, p_fill} are in a different group from {z_spill, p_spill}). This is a bit of a trade-off where we choose to keep the instruction classes simpler and easier to look up from the spec, as opposed to minimising the lines of code. The other reason is that merging e.g. z_fill and p_fill - both in the same encoding group - is not very convenient because they have different encodings for their operands (e.g. 5-bits Zt vs 4-bits Pt) and also different operands (ZPRAny vs PPRAny). I think it doesn't make it easier to read if we are to template these cases.
Does that make sense?

Are you referring to the 'assembler syntax' table? I think this table needs to be read in conjunction with the following paragraph (section 5.2.2, page 42):

In D46121#1082480, @samparker wrote:

Sorry to be pain, but could you point to the document that describes this please? From the supplement, I can't see why a shifted operand is invalid.

Hi Sam, if you download the spec from:

https://developer.arm.com/docs/ddi0584/latest/arm-architecture-reference-manual-supplement-the-scalable-vector-extension-sve-for-armv8-a

the SVE Supplement links to the SVE Instruction Index in section 5.2.1. This should open the xhtml/index.html page with a list of all the instructions and all their details. For some reason the PDF link doesn't work for me, so opening the index.html directly is probably easiest. (I think the specific file you're looking for is: st1b_z_p_br.html)

In D45958#1077798, @fhahn wrote:

LGTM. Some of the diagnostics can be improved after D45879 lands, I suppose?

Correct!

• Merged sve_mem_64b_gld_sv and sve_mem_64b_gld_sv2 instruction classes.