llvm dev - Jun 2016 - What kind of testcases should be required to test IPRA?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/61d82d67/attachment.html>

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.

-- 
Mehdi



> On Jun 1, 2016, at 9:32 PM, vivek pandya <vivekvpandya at gmail.com>
wrote:
> 
> 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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160605/c436b6b3/attachment.html>