[PATCH] starting from ARMv8, rGPR includes SP

Artyom Skrobov artyom.skrobov at arm.com
Mon Jun 22 13:46:43 PDT 2015


Charlie, thank you for flagging up these issues!

I have edited the first two patches as you suggested, splitting out the NFC
refactoring into a separate patch, and making the additions to the test case
follow the corresponding code changes in the same patch.

Attaching the three new patch files


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

Hi Artyom, thanks for working on this!

Can you use Phabricator in the future, making sure to supply plenty of
context? Most people prefer reviewing using that system :)

First patch,

+  case Match_RequiresV8:
+    return Error(IDLoc, "using SP in this instruction requires ARMv8 or
later");

I see no test for this diagnostic in patch #1, but I do see a test in patch
#2. Is there a good reason why these patches can't be reworked to test what
the introduce in the same commit?

+  else if (isThumbOne()) {
+    // Some high-register supporting Thumb1 encodings only allow both
registers
+    // to be from r0-r7 when in Thumb2.
+    if (Opc == ARM::tADDhirr && !hasV6MOps() &&
+        isARMLowRegister(Inst.getOperand(1).getReg()) &&
+        isARMLowRegister(Inst.getOperand(2).getReg()))
+      return Match_RequiresThumb2;
+    // Others only require ARMv6 or later.
+    else if (Opc == ARM::tMOVr && !hasV6Ops() &&
+             isARMLowRegister(Inst.getOperand(0).getReg()) &&
+             isARMLowRegister(Inst.getOperand(1).getReg()))
+      return Match_RequiresV6;
+  }

Please try and keep no functional changes like this separate.

As per John's comment, I agree that would be better, but I couldn't figure
out how to do that when making the last change to BXJ.
I don't see a better way of doing this selection based on the target. The
modelling of unpredictable instructions seems tricky with everything being
statically generated as it is.

--Charlie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Allow-SP-in-rGPR-starting-from-ARMv8-assembly.patch
Type: application/octet-stream
Size: 1794 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150622/996fcf57/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-SP-and-PC-as-shifted-reg-operands-are-unpredictable-.patch
Type: application/octet-stream
Size: 6072 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150622/996fcf57/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Refactoring-ARMAsmParser-checkTargetMatchPredicate-N.patch
Type: application/octet-stream
Size: 1920 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150622/996fcf57/attachment-0002.obj>


More information about the llvm-commits mailing list