Use function attribute "arm-restrict-it"

[ahatanak]

Summary

This patch changes ARMSubtarget::restrictIT to use the function attribute "arm-restrict-it" to decide whether ARMv7 or v8 style IT blocks should be generated.

IThe corresponding clang patch is here: http://reviews.llvm.org/D10414

[rengolin]

I'm confused. You removed the back-end option in Clang, but it remains here (IT), meaning you now have two identical command line options that do things slightly different. The function attributes set IT behaviour on every function and the backend option that sets it in a module level.

This will create a confusing environment on which to develop things and I don't want to extend this pattern. If the option needs to be on a function basis, than we need to make sure that whatever generates IR does that on a function level, and free the backend from having to ponder about module level options.

In summary, IT options must go. :)

cheers,
--renato

[echristo]

Hi Renato,

We've always had two options for this sort of thing, just much more
horribly implemented. :)

Basically the backend developers want to be able to override (largely for
debugging purposes) the "default" for whether or not to construct IT
blocks. It's just overriding the source level and it's good that we can do
this without having developers overwrite the source themselves (it could be
quite large).

I've delayed on reviewing this patch because I'm not quite sure how I want
particular target options to be passed to the backend, but in general the
idea of the patch ("allow the backend to override the IR") isn't a bad
thing.

-eric

[rengolin]

In D10416#191097, @echristo wrote:

We've always had two options for this sort of thing, just much more
horribly implemented. :)

I see. It is hidden, and it has the exact same behaviour (tri-state, isARMv8() on default, implemented in the same function), so I guess it's ok.

The chances that people will abuse of this relationship or will change one and not the other is indeed, minimal.

cheers,
--renato

[compnerd]

lib/Target/ARM/ARMSubtarget.cpp

232

Bikeshedding: I think that restrictedIT might be a better name. IIRC, the ARM ARM refers to this as Restricted IT Blocks.

test/CodeGen/Thumb2/restict-it-fnattr.ll

13

This test slightly concerns me. With Restricted IT blocks, IT blocks are only constructed under certain circumstances on ARMv7. Do you mind adding a bit more context around the test by adding -NEXT checks to ensure that the instructions within the IT blocks are exactly what we expect?

[ahatanak]

In D10416#191108, @rengolin wrote:

In D10416#191097, @echristo wrote:

We've always had two options for this sort of thing, just much more
horribly implemented. :)

I see. It is hidden, and it has the exact same behaviour (tri-state, isARMv8() on default, implemented in the same function), so I guess it's ok.

The chances that people will abuse of this relationship or will change one and not the other is indeed, minimal.

Since this is intended to be used only by tools such as llc and opt, we can move the IT option to CodeGen/CommandFlags.h and let setFunctionAttributes rewrite the function attribute in the IR. The downside of this is that we'll be moving a target-specific option into a file that is supposed to be target-independent.

[ahatanak]

Add checks in test case to ensure the instructions within the IT blocks are exactly what we expect.

[ahatanak]

lib/Target/ARM/ARMSubtarget.cpp

232

I'm not sure whether restrictIT is a good name or not, but if we are going to rename it, should we use a verb like "useRestrictedIT" as llvm's coding style guide recommends?

[ahatanak]

Following the discussion on cfe-commits (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150622/thread.html#131397), I've made changes to define a new ARM subtarget feature and use it to determine if IT blocks should be restricted. Previously, ARMSubtarget would check if the target supports armv8 instructions to make this decision. This is no longer needed as that decision is made in the front-end (see the corresponding clang patch: http://reviews.llvm.org/D10414).

[echristo]

I think you want to turn on restrict-it here:

def HasV8Ops : SubtargetFeature<"v8", "HasV8Ops", "true",

"Support ARM v8 instructions",
[HasV7Ops, FeatureVirtualization,
 FeatureMP]>;

by default yes?

-eric

[ahatanak]

Are you suggesting adding FeatureRestrictedIT to the implied feature list of HasV8Ops? I thought about doing so but found out it would make it impossible to disable restrict-it when we target v8. Try compiling the following IR with -mattr=-restrict-it after adding FeatureRestrictedIT to the implied feature list:

$ cat f1.ll
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "armv8--linux-gnueabi"

define void @test_inlineasm() {
entry:

tail call void asm sideeffect "hlt #64", ""()
ret void

}

$ llc f1.ll -o - -mattr=-restrict-it
<inline asm>:1:2: error: instruction requires: armv8

hlt #64
^

LLVM ERROR: Error parsing inline asm

This fails because disabling restrict-it transitively disables HasV8Ops too (see function ClearImpliedBits in SubtargetFeature.cpp).

If I compile the IR with trunk's llc with command line option -arm-no-restrict-it, it compiles without any errors.

$ llc f1.ll -o - -arm-no-restrict-it

Do we need the capability to turn off disable restrict-it when targeting armv8? I was assuming we do need it although I wasn't sure why users would want to do that.

[echristo]

In D10416#198657, @ahatanak wrote:

Are you suggesting adding FeatureRestrictedIT to the implied feature list of HasV8Ops? I thought about doing so but found out it would make it impossible to disable restrict-it when we target v8. Try compiling the following IR with -mattr=-restrict-it after adding FeatureRestrictedIT to the implied feature list:

Fascinating.

This fails because disabling restrict-it transitively disables HasV8Ops too (see function ClearImpliedBits in SubtargetFeature.cpp).

Right.

If I compile the IR with trunk's llc with command line option -arm-no-restrict-it, it compiles without any errors.

$ llc f1.ll -o - -arm-no-restrict-it

Do we need the capability to turn off disable restrict-it when targeting armv8? I was assuming we do need it although I wasn't sure why users would want to do that.

I don't know. I wouldn't think so tbh which is why I just suggested putting it as a feature on the subarchitecture.

Jim?

-eric

[ahatanak]

r194592's commit log seems to suggest that both options were added to make llvm compatible with gcc.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131111/194792.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131111/194452.html

I guess we shouldn't disallow users to use "-mno-restrict-it" for ARMv8 even if it doesn't make much sense?

[echristo]

That was my thought. Let's have Jim weigh in because I like throwing him under this bus :)

-eric

[grosbach]

For the backend attribute, having -arm-restrict-it (or equivalent) transitively disable HasV8Ops is really, really bad. Those should be completely independent selections. The former is about tuning instruction selection (via if-conversion in this case) based on the microarchitecture. The latter is about which instructions are available in the first place. The former does not imply the latter.

I don't think there's much point to disabling restrict-it when targeting v8 from an end-user POV, but it's pretty useful for the backend. We want to be able to write test cases that make sure it's working, for example.

Do I understand right there's a frontend option, too? That's the only context in which gcc compatibility makes much sense. I don't see any value other than slavishly following gcc's option list to having this be exposed to end users in clang. I'd much rather it be entirely in the backend.

[ahatanak]

In D10416#241642, @grosbach wrote:

For the backend attribute, having -arm-restrict-it (or equivalent) transitively disable HasV8Ops is really, really bad. Those should be completely independent selections. The former is about tuning instruction selection (via if-conversion in this case) based on the microarchitecture. The latter is about which instructions are available in the first place. The former does not imply the latter.

I think we want to discuss whether the latter (HasV8Ops) implies the former (restrict-it). If it makes no sense from the user's POV to not restrict IT blocks when targeting armv8, then we can conclude armv8 implies restrict-it and add FeatureRestrictedIT to the implied features list of HasV8Ops. If we do this, disabling restrict-it would transitively disable HasV8Ops. Does that make sense?

I don't think there's much point to disabling restrict-it when targeting v8 from an end-user POV, but it's pretty useful for the backend. We want to be able to write test cases that make sure it's working, for example.

That said, if we want to allow llvm developers to turn off restrict-it when targeting v8 for debugging purposes, we shouldn't add FeatureRestrictedIT to the implied features list of HasV8Ops.

Do I understand right there's a frontend option, too? That's the only context in which gcc compatibility makes much sense. I don't see any value other than slavishly following gcc's option list to having this be exposed to end users in clang. I'd much rather it be entirely in the backend.

The front-end options are -mrestrict-it and -mno-restrict-it, which were committed in r194593. The clang-side patch that I submitted for review is here: http://reviews.llvm.org/D10414.

I agree that the option to disable restrict-it when targeting armv8 should be a backend option only available to llvm developers. If we all agree on that, I'll update the clang patch (D10414) accordingly.

No changes are needed to the llvm patch (this patch) to allow disabling restrict-it when targeting armv8. If -mattr=+restrict-it is not on the tool's (llc's) command line, restrict-it is disabled.

[grosbach]

In D10416#241764, @ahatanak wrote:

In D10416#241642, @grosbach wrote:

For the backend attribute, having -arm-restrict-it (or equivalent) transitively disable HasV8Ops is really, really bad. Those should be completely independent selections. The former is about tuning instruction selection (via if-conversion in this case) based on the microarchitecture. The latter is about which instructions are available in the first place. The former does not imply the latter.

I think we want to discuss whether the latter (HasV8Ops) implies the former (restrict-it). If it makes no sense from the user's POV to not restrict IT blocks when targeting armv8, then we can conclude armv8 implies restrict-it and add FeatureRestrictedIT to the implied features list of HasV8Ops. If we do this, disabling restrict-it would transitively disable HasV8Ops. Does that make sense?

It makes sense right up until you say, "If we do this, disabling restrict-it would transitively disable HasV8Ops." That may be the current implementation, but it's not what we want.

I don't think there's much point to disabling restrict-it when targeting v8 from an end-user POV, but it's pretty useful for the backend. We want to be able to write test cases that make sure it's working, for example.

That said, if we want to allow llvm developers to turn off restrict-it when targeting v8 for debugging purposes, we shouldn't add FeatureRestrictedIT to the implied features list of HasV8Ops.

Right. We want it to be the case by default for armv8, but not inextricably tied to it. It's a default, not a requirement.

Do I understand right there's a frontend option, too? That's the only context in which gcc compatibility makes much sense. I don't see any value other than slavishly following gcc's option list to having this be exposed to end users in clang. I'd much rather it be entirely in the backend.

The front-end options are -mrestrict-it and -mno-restrict-it, which were committed in r194593. The clang-side patch that I submitted for review is here: http://reviews.llvm.org/D10414.

I agree that the option to disable restrict-it when targeting armv8 should be a backend option only available to llvm developers. If we all agree on that, I'll update the clang patch (D10414) accordingly.

No changes are needed to the llvm patch (this patch) to allow disabling restrict-it when targeting armv8. If -mattr=+restrict-it is not on the tool's (llc's) command line, restrict-it is disabled.

[ahatanak]

Perhaps I should ask Weiming who committed the original patch to add these options just to be sure.

Is there a use case in which an end user wants to disable restrict-it when targeting armv8?

Would there be problems if we stopped exposing option -mno-restrict-it to the end user as suggested by Jim? I'm considering making changes to clang so that -mno-restrict-it has no effect on the backend code generation (end-users can use the option but it'll have no effect).

[weimingz]

Hi Akira,

Yes, the option "-mno-restrict-it " was added for GCC compatibility. I don't find a actual use case :)
So I think it should be OK to move to backend option only

In D10416#241967, @ahatanak wrote:

Perhaps I should ask Weiming who committed the original patch to add these options just to be sure.

Is there a use case in which an end user wants to disable restrict-it when targeting armv8?

Would there be problems if we stopped exposing option -mno-restrict-it to the end user as suggested by Jim? I'm considering making changes to clang so that -mno-restrict-it has no effect on the backend code generation (end-users can use the option but it'll have no effect).

[ahatanak]

In D10416#242134, @weimingz wrote:

Hi Akira,

Yes, the option "-mno-restrict-it " was added for GCC compatibility. I don't find a actual use case :)
So I think it should be OK to move to backend option only

OK, I'll make changes to clang to stop exposing it to the end-user as a front-end option.

[ahatanak]

Rebase to r247192 and remove a RUN line in test/CodeGen/Thumb2/restict-it-fnattr.ll that is no longer needed.

lib/Target/ARM/ARM.td

 def FeatureAvoidPartialCPSR : SubtargetFeature<"avoid-partial-cpsr",
                                                "AvoidCPSRPartialUpdate", "true",
                                  "Avoid CPSR partial update for OOO execution">;
 
 def FeatureAvoidMOVsShOp : SubtargetFeature<"avoid-movs-shop",
                                             "AvoidMOVsShifterOperand", "true",
                                 "Avoid movs instructions with shifter operand">;
 
+def FeatureRestrictedIT : SubtargetFeature<"restrict-it", "RestrictIT", "true",
+                                           "Restrict generation of IT blocks">;
+
 // Some processors perform return stack prediction. CodeGen should avoid issue
 // "normal" call instructions to callees which do not return.
 def FeatureHasRAS : SubtargetFeature<"ras", "HasRAS", "true",
                                      "Has return address stack">;
 
 /// Some M architectures don't have the DSP extension (v7E-M vs. v7M)
 def FeatureDSPThumb2 : SubtargetFeature<"t2dsp", "Thumb2DSP", "true",
                                  "Supports v7 DSP instructions in Thumb2">;

lib/Target/ARM/ARMSubtarget.cpp

 #define GET_SUBTARGETINFO_TARGET_DESC
 #define GET_SUBTARGETINFO_CTOR
 #include "ARMGenSubtargetInfo.inc"
 
 static cl::opt<bool>
 UseFusedMulOps("arm-use-mulops",
                cl::init(true), cl::Hidden);
 
-enum ITMode {
-  DefaultIT,
-  RestrictedIT,
-  NoRestrictedIT
-};
-
-static cl::opt<ITMode>
-IT(cl::desc("IT block support"), cl::Hidden, cl::init(DefaultIT),
-   cl::ZeroOrMore,
-   cl::values(clEnumValN(DefaultIT, "arm-default-it",
-                         "Generate IT block based on arch"),
-              clEnumValN(RestrictedIT, "arm-restrict-it",
-                         "Disallow deprecated IT based on ARMv8"),
-              clEnumValN(NoRestrictedIT, "arm-no-restrict-it",
-                         "Allow IT blocks based on ARMv7"),
-              clEnumValEnd));
-
 /// initializeSubtargetDependencies - Initializes using a CPU and feature string
 /// so that we can use initializer lists for subtarget initialization.
 ARMSubtarget &ARMSubtarget::initializeSubtargetDependencies(StringRef CPU,
                                                             StringRef FS) {
   initializeEnvironment();
   initSubtargetFeatures(CPU, FS);
   return *this;
 }
void ARMSubtarget::initializeEnvironment() {
   HasCrypto = false;
   HasCRC = false;
   HasZeroCycleZeroing = false;
   StrictAlign = false;
   Thumb2DSP = false;
   UseNaClTrap = false;
   GenLongCalls = false;
   UnsafeFPMath = false;
+  RestrictIT = false;
 }
 
 void ARMSubtarget::initSubtargetFeatures(StringRef CPU, StringRef FS) {
   if (CPUString.empty()) {
     if (isTargetDarwin() && TargetTriple.getArchName().endswith("v7s"))
       // Default to the Swift CPU when targeting armv7s/thumbv7s.
       CPUString = "swift";
     else
void ARMSubtarget::initSubtargetFeatures(StringRef CPU, StringRef FS) {
   if (isTargetNaCl())
     stackAlignment = 16;
 
   if (isTargetMachO())
     SupportsTailCall = !isTargetIOS() || !getTargetTriple().isOSVersionLT(5, 0);
   else
     SupportsTailCall = !isThumb1Only();
 
-  switch (IT) {
-  case DefaultIT:
-    RestrictIT = hasV8Ops();
-    break;
-  case RestrictedIT:
-    RestrictIT = true;
-    break;
-  case NoRestrictedIT:
-    RestrictIT = false;
-    break;
-  }
-
   // NEON f32 ops are non-IEEE 754 compliant. Darwin is ok with it by default.
   const FeatureBitset &Bits = getFeatureBits();
   if ((Bits[ARM::ProcA5] || Bits[ARM::ProcA8]) && // Where this matters
       (Options.UnsafeFPMath || isTargetDarwin()))
     UseNEONForSinglePrecisionFP = true;
 }
 
 bool ARMSubtarget::isAPCS_ABI() const {
if (RelocM == Reloc::PIC_) {
         // Hidden $non_lazy_ptr reference.
         return true;
     }
   }
 
   return false;
 }
 
 unsigned ARMSubtarget::getMispredictionPenalty() const {
   return SchedModel.MispredictPenalty;
 }
 
 bool ARMSubtarget::hasSinCos() const {
   return getTargetTriple().isiOS() && !getTargetTriple().isOSVersionLT(7, 0);
 }
 
 bool ARMSubtarget::enableMachineScheduler() const {

test/CodeGen/ARM/2013-05-05-IfConvertBug.ll

 ; RUN: llc < %s -mtriple=thumbv7-apple-ios -mcpu=cortex-a8 | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv8 | FileCheck -check-prefix=CHECK-V8 %s
-; RUN: llc < %s -mtriple=thumbv7 -arm-restrict-it | FileCheck -check-prefix=CHECK-V8 %s
+; RUN: llc < %s -mtriple=thumbv8 -mattr=+restrict-it | FileCheck -check-prefix=CHECK-V8 %s
+; RUN: llc < %s -mtriple=thumbv7 -mattr=+restrict-it | FileCheck -check-prefix=CHECK-V8 %s
 ; rdar://13782395
 
 define i32 @t1(i32 %a, i32 %b, i8** %retaddr) {
 ; CHECK-LABEL: t1:
 ; CHECK: Block address taken
 ; CHECK-NOT: Address of block that was removed by CodeGen
   store i8* blockaddress(@t1, %cond_true), i8** %retaddr
   %tmp2 = icmp eq i32 %a, 0

test/CodeGen/ARM/2014-08-04-muls-it.ll

-; RUN: llc -mtriple thumbv7-eabi -arm-restrict-it -filetype asm -o - %s \
+; RUN: llc -mtriple thumbv7-eabi -mattr=+restrict-it -filetype asm -o - %s \
 ; RUN:    | FileCheck %s
 
 define arm_aapcscc i32 @function(i32 %i, i32 %j) {
 entry:
   %cmp = icmp eq i32 %i, %j
   br i1 %cmp, label %if.then, label %if.end
 
 if.then:                                          ; preds = %entry

test/CodeGen/ARM/arm-and-tst-peephole.ll

 ; RUN: llc -mtriple=arm-eabi -arm-atomic-cfg-tidy=0 %s -o - | FileCheck -check-prefix=ARM %s
 ; RUN: llc -mtriple=thumb-eabi -arm-atomic-cfg-tidy=0 %s -o - | FileCheck -check-prefix=THUMB %s
 ; RUN: llc -mtriple=thumb-eabi -arm-atomic-cfg-tidy=0 -mcpu=arm1156t2-s -mattr=+thumb2 %s -o - \
 ; RUN:   | FileCheck -check-prefix=T2 %s
-; RUN: llc -mtriple=thumbv8-eabi -arm-atomic-cfg-tidy=0 %s -o - | FileCheck -check-prefix=V8 %s
+; RUN: llc -mtriple=thumbv8-eabi -arm-atomic-cfg-tidy=0 -mattr=+restrict-it %s -o - | FileCheck -check-prefix=V8 %s
 
 ; FIXME: The -march=thumb test doesn't change if -disable-peephole is specified.
 
 %struct.Foo = type { i8* }
 
 ; ARM-LABEL:   foo:
 ; THUMB-LABEL: foo:
 ; T2-LABEL:    foo:

test/CodeGen/ARM/ifcvt-branch-weight.ll

-; RUN: llc < %s -mtriple=thumbv8 -print-machineinstrs=if-converter -arm-atomic-cfg-tidy=0 -o /dev/null 2>&1 | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8 -print-machineinstrs=if-converter -arm-atomic-cfg-tidy=0 -mattr=+restrict-it -o /dev/null 2>&1 | FileCheck %s
 
 %struct.S = type { i8* (i8*)*, [1 x i8] }
 define internal zeroext i8 @bar(%struct.S* %x, %struct.S* nocapture %y) nounwind readonly {
 entry:
   %0 = getelementptr inbounds %struct.S, %struct.S* %x, i32 0, i32 1, i32 0
   %1 = load i8, i8* %0, align 1
   %2 = zext i8 %1 to i32
   %3 = and i32 %2, 112

test/CodeGen/ARM/thumb2-it-block.ll

 ; RUN: llc -mtriple=thumb-eabi -mcpu=arm1156t2-s -mattr=+thumb2 %s -o - | FileCheck %s
-; RUN: llc -mtriple=thumbv8 %s -o - | FileCheck %s
+; RUN: llc -mtriple=thumbv8 -mattr=+restrict-it %s -o - | FileCheck %s
 ; PR11107
 
 define i32 @test(i32 %a, i32 %b) {
 entry:
  %cmp1 = icmp slt i32 %a, 0
  %sub1 = sub nsw i32 0, %a
  %abs1 = select i1 %cmp1, i32 %sub1, i32 %a
  %cmp2 = icmp slt i32 %b, 0

test/CodeGen/Thumb2/restict-it-fnattr.ll

+; RUN: llc < %s -mtriple=thumbv7 -mcpu=cortex-a8 | FileCheck %s -check-prefix=NO-OPTION
+; RUN: llc < %s -mtriple=thumbv7 -mcpu=cortex-a8 -mattr=+restrict-it | FileCheck %s -check-prefix=RESTRICT-IT
+
+; NO-OPTION-LABEL: {{\_?}}no_restrict_it:
+; NO-OPTION: itt gt
+; NO-OPTION-NEXT: addgt
+; NO-OPTION-NEXT: addgt
+
+; RESTRICT-IT-LABEL: {{\_?}}no_restrict_it:
+; RESTRICT-IT: it gt
+; RESTRICT-IT-NEXT: addgt
+; RESTRICT-IT: it gt
+; RESTRICT-IT-NEXT: addgt
+
+define i32 @no_restrict_it(i32 %a, i32 %b) {
+entry:
+  %cmp = icmp sgt i32 %a, 5
+  br i1 %cmp, label %if.then, label %if.end
+
+if.then:
+  %add0 = add nsw i32 %a, 1
+  %add1 = add nsw i32 %b, 2
+  br label %if.end
+
+if.end:
+  %t0.0 = phi i32 [ %add0, %if.then ], [ %a, %entry ]
+  %t1.0 = phi i32 [ %add1, %if.then ], [ %b, %entry ]
+  %mul = mul nsw i32 %t1.0, %t0.0
+  ret i32 %mul
+}
+
+; NO-OPTION-LABEL: {{\_?}}restrict_it:
+; NO-OPTION: it gt
+; NO-OPTION-NEXT: addgt
+; NO-OPTION: it gt
+; NO-OPTION-NEXT: addgt
+
+; RESTRICT-IT-LABEL: {{\_?}}restrict_it:
+; RESTRICT-IT: it gt
+; RESTRICT-IT-NEXT: addgt
+; RESTRICT-IT: it gt
+; RESTRICT-IT-NEXT: addgt
+
+define i32 @restrict_it(i32 %a, i32 %b) #0 {
+entry:
+  %cmp = icmp sgt i32 %a, 5
+  br i1 %cmp, label %if.then, label %if.end
+
+if.then:
+  %add0 = add nsw i32 %a, 1
+  %add1 = add nsw i32 %b, 2
+  br label %if.end
+
+if.end:
+  %t0.0 = phi i32 [ %add0, %if.then ], [ %a, %entry ]
+  %t1.0 = phi i32 [ %add1, %if.then ], [ %b, %entry ]
+  %mul = mul nsw i32 %t1.0, %t0.0
+  ret i32 %mul
+}
+
+attributes #0 = { "target-features"="+restrict-it" }

test/CodeGen/Thumb2/thumb2-ifcvt1.ll

 ; RUN: llc < %s -mtriple=thumbv7-apple-darwin | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7-apple-darwin -arm-default-it | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv8 -arm-no-restrict-it |FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7-apple-darwin | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8 | FileCheck %s
 define i32 @t1(i32 %a, i32 %b, i32 %c, i32 %d) nounwind {
 ; CHECK-LABEL: t1:
 ; CHECK: ittt ne
 ; CHECK: cmpne
 ; CHECK: addne
 ; CHECK: bxne lr
   switch i32 %c, label %cond_next [
      i32 1, label %cond_true

test/CodeGen/Thumb2/thumb2-ifcvt2.ll

 ; RUN: llc < %s -mtriple=thumbv7-apple-ios -arm-atomic-cfg-tidy=0 | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7-apple-ios -arm-atomic-cfg-tidy=0 -arm-default-it | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv8-apple-ios -arm-atomic-cfg-tidy=0 -arm-no-restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7-apple-ios -arm-atomic-cfg-tidy=0 | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8-apple-ios -arm-atomic-cfg-tidy=0 | FileCheck %s
 
 define void @foo(i32 %X, i32 %Y) {
 entry:
 ; CHECK-LABEL: foo:
 ; CHECK: it ne
 ; CHECK: cmpne
 ; CHECK: it hi
 ; CHECK: pophi {r7, pc}

test/CodeGen/Thumb2/thumb2-ifcvt3.ll

 ; RUN: llc < %s -mtriple=thumbv7-apple-darwin -arm-atomic-cfg-tidy=0 | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7-apple-darwin -arm-atomic-cfg-tidy=0 -arm-default-it | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv8-apple-darwin -arm-atomic-cfg-tidy=0 -arm-no-restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7-apple-darwin -arm-atomic-cfg-tidy=0 | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8-apple-darwin -arm-atomic-cfg-tidy=0 | FileCheck %s
 
 ; There shouldn't be a unconditional branch at end of bb52.
 ; rdar://7184787
 
 @posed = external global i64                      ; <i64*> [#uses=1]
 
 define i1 @ab_bb52(i64 %.reload78, i64* %.out, i64* %.out1) nounwind {
 newFuncRoot:

test/CodeGen/Thumb2/v8_IT_1.ll

-; RUN: llc < %s -mtriple=thumbv8 -mattr=+neon | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7 -mattr=+neon -arm-restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8 -mattr=+neon -mattr=+restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7 -mattr=+neon -mattr=+restrict-it | FileCheck %s
 
 ;CHECK-LABEL: select_s_v_v:
 ;CHECK-NOT: it
 ;CHECK: bx
 define <16 x i8> @select_s_v_v(i32 %avail, i8* %bar) {
 entry:
   %vld1 = call <16 x i8> @llvm.arm.neon.vld1.v16i8(i8* %bar, i32 1)
   %and = and i32 %avail, 1
   %tobool = icmp eq i32 %and, 0
   %vld1. = select i1 %tobool, <16 x i8> %vld1, <16 x i8> zeroinitializer
   ret <16 x i8> %vld1.
 }
 
 declare <16 x i8> @llvm.arm.neon.vld1.v16i8(i8* , i32 )
 

test/CodeGen/Thumb2/v8_IT_2.ll

-; RUN: llc < %s -mtriple=thumbv8 | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7 -arm-restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8 -mattr=+restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7 -mattr=+restrict-it | FileCheck %s
 
   %struct.quad_struct = type { i32, i32, %struct.quad_struct*, %struct.quad_struct*, %struct.quad_struct*, %struct.quad_struct*, %struct.quad_struct* }
 
 define fastcc i32 @CountTree(%struct.quad_struct* %tree) {
 entry:
 ; CHECK-LABEL: CountTree:
 ; CHECK: bne
 ; CHECK: cmp

test/CodeGen/Thumb2/v8_IT_3.ll

-; RUN: llc < %s -mtriple=thumbv8 -arm-atomic-cfg-tidy=0 | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7 -arm-atomic-cfg-tidy=0 -arm-restrict-it | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv8 -arm-atomic-cfg-tidy=0 -relocation-model=pic | FileCheck %s --check-prefix=CHECK-PIC
-; RUN: llc < %s -mtriple=thumbv7 -arm-atomic-cfg-tidy=0 -arm-restrict-it -relocation-model=pic | FileCheck %s --check-prefix=CHECK-PIC
+; RUN: llc < %s -mtriple=thumbv8 -arm-atomic-cfg-tidy=0 -mattr=+restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7 -arm-atomic-cfg-tidy=0 -mattr=+restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8 -arm-atomic-cfg-tidy=0 -mattr=+restrict-it -relocation-model=pic | FileCheck %s --check-prefix=CHECK-PIC
+; RUN: llc < %s -mtriple=thumbv7 -arm-atomic-cfg-tidy=0 -mattr=+restrict-it -relocation-model=pic | FileCheck %s --check-prefix=CHECK-PIC
 
 %struct.FF = type { i32 (i32*)*, i32 (i32*, i32*, i32, i32, i32, i32)*, i32 (i32, i32, i8*)*, void ()*, i32 (i32, i8*, i32*)*, i32 ()* }
 %struct.BD = type { %struct.BD*, i32, i32, i32, i32, i64, i32 (%struct.BD*, i8*, i64, i32)*, i32 (%struct.BD*, i8*, i32, i32)*, i32 (%struct.BD*, i8*, i64, i32)*, i32 (%struct.BD*, i8*, i32, i32)*, i32 (%struct.BD*, i64, i32)*, [16 x i8], i64, i64 }
 
 @FuncPtr = external hidden unnamed_addr global %struct.FF*
 @.str1 = external hidden unnamed_addr constant [6 x i8], align 4
 @G = external unnamed_addr global i32
 @.str2 = external hidden unnamed_addr constant [58 x i8], align 4

test/CodeGen/Thumb2/v8_IT_4.ll

-; RUN: llc < %s -mtriple=thumbv8-eabi -float-abi=hard | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7-eabi -float-abi=hard -arm-restrict-it | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv8-eabi -float-abi=hard -regalloc=basic | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7-eabi -float-abi=hard -regalloc=basic -arm-restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8-eabi -float-abi=hard -mattr=+restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7-eabi -float-abi=hard -mattr=+restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8-eabi -float-abi=hard -regalloc=basic -mattr=+restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7-eabi -float-abi=hard -regalloc=basic -mattr=+restrict-it | FileCheck %s
 
 %"struct.__gnu_cxx::__normal_iterator<char*,std::basic_string<char, std::char_traits<char>, std::allocator<char> > >" = type { i8* }
 %"struct.__gnu_cxx::new_allocator<char>" = type <{ i8 }>
 %"struct.std::basic_string<char,std::char_traits<char>,std::allocator<char> >" = type { %"struct.__gnu_cxx::__normal_iterator<char*,std::basic_string<char, std::char_traits<char>, std::allocator<char> > >" }
 %"struct.std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Rep" = type { %"struct.std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Rep_base" }
 %"struct.std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Rep_base" = type { i32, i32, i32 }
 
 

test/CodeGen/Thumb2/v8_IT_5.ll

-; RUN: llc < %s -mtriple=thumbv8 -arm-atomic-cfg-tidy=0 | FileCheck %s
-; RUN: llc < %s -mtriple=thumbv7 -arm-atomic-cfg-tidy=0 -arm-restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv8 -arm-atomic-cfg-tidy=0 -mattr=+restrict-it | FileCheck %s
+; RUN: llc < %s -mtriple=thumbv7 -arm-atomic-cfg-tidy=0 -mattr=+restrict-it | FileCheck %s
 ; CHECK: it ne
 ; CHECK-NEXT: cmpne
 ; CHECK-NEXT: bne [[JUMPTARGET:.LBB[0-9]+_[0-9]+]]
 ; CHECK: cbz
 ; CHECK-NEXT: %if.else163
 ; CHECK-NEXT: mov.w
 ; CHECK-NEXT: b
 ; CHECK: [[JUMPTARGET]]:{{.*}}%if.else173