FW: [PATCH] starting from ARMv8, rGPR includes SP

[Artyom Skrobov via llvm-commits]

Hello James,

Thank you for reviewing my set of patches a few months ago, and explaining
why re-including ARMGenInstrInfo.inc wasn't a good idea :)

Still, the other four patches (I'm re-attaching them to this email) seem to
remain valid, addressing issues that still exist with ARMv8 32-bit assembly
/ disassembly.

I have checked these patches again now; they apply with no conflicts, and
they don't upset any tests.

Would it be OK to commit just these four?

The original description of the patches is quoted below.


-----Original Message-----
From: Artyom Skrobov [mailto:artyom.skrobov at arm.com] 
Sent: 22 June 2015 10:08
To: llvm-commits at cs.uiuc.edu
Cc: Charlie Turner; 'tnorthover at apple.com'; 'Renato Golin';
'amaury.dlv at gmail.com'; 'resistor at mac.com'
Subject: [PATCH] starting from ARMv8, rGPR includes SP

Hello,

A set of six patches, more or less independent one from another, are
attached for review.

The people who were last to contribute to the code that my patches are
changing are on CC: 

The first patch fixes a long-standing error in the assembler which allowed
SP and PC as shifted-reg operands in ARMv7 Thumb -- despite correctly
rejecting the same registers when not shifted.
A test case which appeared to enshrine this incorrect treatment,
test/MC/ARM/thumb-shift-encoding.s, was committed by Tim back in 2012; my
patch fixes his test, and moves the invalid instructions into
test/MC/ARM/thumb2-diagnostics.s

The second patch adds a case for MCK_rGPR into
ARMAsmParser::validateTargetOperandClass, to allow SP in rGPR, when
assembling for ARMv8 Thumb.
The third patch, similarly, extends DecoderGPRRegisterClass to allow SP in
rGPR, when disassembling ARMv8 Thumb; and changes DecodeSORegImmOperand to
disallow PC (and optionally SP) even when shifted.
The existing implementation of DecodeSORegImmOperand was committed by Owen
in 2011; and of DecoderGPRRegisterClass, by Amaury in 2013.

The next patch includes ARMGenInstrInfo.inc for a second time, after
re-defining rGPRRegClassID, in order to enable the codegen to use the new
encodings that become available in ARMv8 Thumb.
This patch includes a small tweak to InstrInfoEmitter, so that
ARMInstrNameData and ARMInstrNameIndices don't get re-defined.
It also requires to make the getXxxDeprecationInfo predicate functions
non-static.
The code changed by this patch was committed by Tim in 2013.

The last two patches are to revert the special case for BXJ, conditionally
accepting either a GPRnopc or a rGRP operand; and to make
test/MC/ARM/diagnostics.s and test/MC/ARM/thumb2-diagnostics.s more
encompassing, by checking both ARMv7 and ARMv8 handling.
The BXJ patch was committed by Charlie, after review by Renato, just two
month ago.

Any comments on these patches?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-SP-and-PC-as-shifted-reg-operands-are-unpredictable-.patch
Type: application/octet-stream
Size: 6383 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151021/e0a993e1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Allow-SP-in-rGPR-starting-from-ARMv8-assembly.patch
Type: application/octet-stream
Size: 1934 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151021/e0a993e1/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Allow-SP-in-rGPR-starting-from-ARMv8-disassembly.patch
Type: application/octet-stream
Size: 4097 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151021/e0a993e1/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Enable-tests-for-invalid-instructions-to-run-on-both.patch
Type: application/octet-stream
Size: 6457 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151021/e0a993e1/attachment-0003.obj>