What kind of testcases should be required to test IPRA?

vivekvpandya · June 2, 2016, 4:32am

Dear Mentors,

I will be writing test cases for IPRA for lit infrastructure.

Following 2 basic test cases I have identified :

Program that does not have recursive function call.
Program that does have recursive calls.

Please suggest some other test cases or provide some hints.

Sincerely,
Vivek

mehdi_amini · June 2, 2016, 4:55am

Hi,

I'd start with the most simple test I can imagine:

target triple = "x86_64-unknown-unknown"
define void @bar1() {
    ret void
}
define preserve_allcc void @foo() #0 {
    call void @bar1()
    call void @bar2()
    ret void
}
define void @bar2() {
    ret void
}
attributes #0 = { nounwind }

It is designed such that the calling convention on foo are more conservative than the calling convention on bar1 and bar2. That way running it through llc should force foo to preserve all the registers that are not preserved by bar1 and bar2.
I'd run it two times through llc: the first one without ipra to check that the spill occurs, and the second one with ipra and checking that the spill does not occur.

There are two calls to bar1 and bar2, defined before and after foo, so that we verify the effect of the CGSCC scheduling.

vivekvpandya · June 5, 2016, 2:56am

Hello Mehdi Amini,

Sorry for slow progress this week but it was due to interesting mistake of mine. I had build llvm with ipra enable by default and that build files were on my path ! Due to that next time I tried to build llvm it was terribly slow (almost 1 hour for 10% build ). I spend to much time on fixing this by playing around with environment variables, cmake options etc.
But I think this is a serious concern, we need to think verify this time complexity other wise building a large software with IPRA enable would be very time consuming.

I studied tets case suggest by you on phabricator, for RegUsageInfo passes I am thinking to print clobbered registers and verify that with FileCheck as expected clobbered register for a particular test-case. Is this approach fine?

I did not find function call to CostModelAnalysis::print() , Is opt -analyze making that call ?
I am not able to find similar option in llc. I can’t use info printed with dbgs() function as release build do not add -debug-only option to llc executable.

For the testcase sent by you earlier I have modified it as following :

;;;;; ip-regallco-simple.ll
; RUN: llc < %s | FileCheck %s -check-prefix=NOIPRA
; RUN: llc < %s -enable-ipra | FileCheck %s
; NOIPRA: foo:
; NOIPRA: pushq %r10
; NOIPRA: pushq %r9
; NOIPRA: pushq %r8
; NOIPRA: callq bar1
; CHECK: foo:
; CHECK-NOT: pushq %r10
; CHECK-NOT: pushq %r9
; CHECK-NOT: pushq %r8
; CHECK: callq bar1
target triple = “x86_64-unknown-unknown”
define void @bar1() {
ret void
}
define preserve_allcc void @foo()#0 {
call void @bar1()
call void @bar2()
ret void
}
define void @bar2() {
ret void
}
attributes #0 = {nounwind}

Is this correct approach to verify spills?

Sincerely,
Vivek

mehdi_amini · June 5, 2016, 3:26am

Hello Mehdi Amini,

Sorry for slow progress this week but it was due to interesting mistake of mine. I had build llvm with ipra enable by default and that build files were on my path ! Due to that next time I tried to build llvm it was terribly slow (almost 1 hour for 10% build ). I spend to much time on fixing this by playing around with environment variables, cmake options etc.
But I think this is a serious concern, we need to think verify this time complexity other wise building a large software with IPRA enable would be very time consuming.

Did you build your own clang in release mode or debug? That makes a very important difference...

I studied tets case suggest by you on phabricator, for RegUsageInfo passes I am thinking to print clobbered registers and verify that with FileCheck as expected clobbered register for a particular test-case. Is this approach fine?

I did not find function call to CostModelAnalysis::print() , Is opt -analyze making that call ?

Yes.
(In general, if you find yourself in a situation where you can find the caller for a function, run in a debugger and set a breakpoint)

I am not able to find similar option in llc.

That's an issue. Looks it may not be feasible to test the analysis in llc with the current infrastructure.

I can't use info printed with dbgs() function as release build do not add -debug-only option to llc executable.

For the testcase sent by you earlier I have modified it as following :
;;;;; ip-regallco-simple.ll
; RUN: llc < %s | FileCheck %s -check-prefix=NOIPRA
; RUN: llc < %s -enable-ipra | FileCheck %s
; NOIPRA: foo:

should be NOIPRA-LABEL:

; NOIPRA: pushq %r10
; NOIPRA: pushq %r9
; NOIPRA: pushq %r8
; NOIPRA: calls bar1

If this is an exact sequence you want to match, you may use NOIPRA-NEXT:

; CHECK: foo:
; CHECK-NOT: pushq %r10
; CHECK-NOT: pushq %r9
; CHECK-NOT: pushq %r8

You can just write "CHECK-NOT: push"

; CHECK: callq bar1
target triple = "x86_64-unknown-unknown"
define void @bar1() {
  ret void
}
define preserve_allcc void @foo()#0 {
  call void @bar1()
  call void @bar2()
  ret void
}
define void @bar2() {
  ret void
}
attributes #0 = {nounwind}

Is this correct approach to verify spills?

Yes.

vivekvpandya · June 5, 2016, 3:32am

>
> Hello Mehdi Amini,
>
> Sorry for slow progress this week but it was due to interesting mistake
of mine. I had build llvm with ipra enable by default and that build files
were on my path ! Due to that next time I tried to build llvm it was
terribly slow (almost 1 hour for 10% build ). I spend to much time on
fixing this by playing around with environment variables, cmake options etc.
> But I think this is a serious concern, we need to think verify this time
complexity other wise building a large software with IPRA enable would be
very time consuming.

Did you build your own clang in release mode or debug? That makes a very
important difference...

oh yes nice point, what I did is Debug mode with IPRA that is insane.

>
> I studied tets case suggest by you on phabricator, for RegUsageInfo
passes I am thinking to print clobbered registers and verify that with
FileCheck as expected clobbered register for a particular test-case. Is
this approach fine?
>
> I did not find function call to CostModelAnalysis::print() , Is opt
-analyze making that call ?

Yes.
(In general, if you find yourself in a situation where you can find the
caller for a function, run in a debugger and set a breakpoint)

Ok

> I am not able to find similar option in llc.

That's an issue. Looks it may not be feasible to test the analysis in llc
with the current infrastructure.

I got the trick, actaully I am trying to do the same thing but let me

figure out why it does not work?
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs=branch-folder -o /dev/null 2>&1 | FileCheck %s
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs -o /dev/null 2>&1 | FileCheck %s
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs= -o /dev/null 2>&1 | FileCheck %s

mehdi_amini · June 5, 2016, 3:45am

I’m not sure what you’re doing here, but considering that llc does not expose -analyze, I’d just keep it all in a single patch as originally planned.

vivekvpandya · June 5, 2016, 4:44am

>
> Hello Mehdi Amini,
>
> Sorry for slow progress this week but it was due to interesting mistake
of mine. I had build llvm with ipra enable by default and that build files
were on my path ! Due to that next time I tried to build llvm it was
terribly slow (almost 1 hour for 10% build ). I spend to much time on
fixing this by playing around with environment variables, cmake options etc.
> But I think this is a serious concern, we need to think verify this
time complexity other wise building a large software with IPRA enable would
be very time consuming.

Did you build your own clang in release mode or debug? That makes a very
important difference...

oh yes nice point, what I did is Debug mode with IPRA that is insane.

>
> I studied tets case suggest by you on phabricator, for RegUsageInfo
passes I am thinking to print clobbered registers and verify that with
FileCheck as expected clobbered register for a particular test-case. Is
this approach fine?
>
> I did not find function call to CostModelAnalysis::print() , Is opt
-analyze making that call ?

Yes.
(In general, if you find yourself in a situation where you can find the
caller for a function, run in a debugger and set a breakpoint)

Ok

> I am not able to find similar option in llc.

That's an issue. Looks it may not be feasible to test the analysis in llc
with the current infrastructure.

I got the trick, actaully I am trying to do the same thing but let me

figure out why it does not work?
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs=branch-folder -o /dev/null 2>&1 | FileCheck %s
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs -o /dev/null 2>&1 | FileCheck %s
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs= -o /dev/null 2>&1 | FileCheck %s

The above example I found in test directory it feeds the .s file to

/dev/null and binds stderr to stdout so that FileCheck will have debug info
printed as input to work on.

I'm not sure what you're doing here, but considering that llc does not

mehdi_amini · June 5, 2016, 4:46am

We could indeed add the dump of the analysis results in doFinalization(), behind a cl::opt.

vivekvpandya · June 5, 2016, 4:56am

>
> Hello Mehdi Amini,
>
> Sorry for slow progress this week but it was due to interesting
mistake of mine. I had build llvm with ipra enable by default and that
build files were on my path ! Due to that next time I tried to build llvm
it was terribly slow (almost 1 hour for 10% build ). I spend to much time
on fixing this by playing around with environment variables, cmake options
etc.
> But I think this is a serious concern, we need to think verify this
time complexity other wise building a large software with IPRA enable would
be very time consuming.

Did you build your own clang in release mode or debug? That makes a very
important difference...

oh yes nice point, what I did is Debug mode with IPRA that is insane.

>
> I studied tets case suggest by you on phabricator, for RegUsageInfo
passes I am thinking to print clobbered registers and verify that with
FileCheck as expected clobbered register for a particular test-case. Is
this approach fine?
>
> I did not find function call to CostModelAnalysis::print() , Is opt
-analyze making that call ?

Yes.
(In general, if you find yourself in a situation where you can find the
caller for a function, run in a debugger and set a breakpoint)

Ok

> I am not able to find similar option in llc.

That's an issue. Looks it may not be feasible to test the analysis in
llc with the current infrastructure.

I got the trick, actaully I am trying to do the same thing but let me

figure out why it does not work?
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs=branch-folder -o /dev/null 2>&1 | FileCheck %s
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs -o /dev/null 2>&1 | FileCheck %s
./print-machineinstrs.ll:; RUN: llc < %s -O3 -debug-pass=Structure
-print-machineinstrs= -o /dev/null 2>&1 | FileCheck %s

The above example I found in test directory it feeds the .s file to

/dev/null and binds stderr to stdout so that FileCheck will have debug info
printed as input to work on.

We could indeed add the dump of the analysis results in doFinalization(),
behind a cl::opt.

Sorry I didn't get that. Please elaborate.