[llvm-dev] What kind of testcases should be required to test IPRA?

[Mehdi Amini via llvm-dev]

> On Jun 4, 2016, at 9:44 PM, vivek pandya <vivekvpandya at gmail.com> wrote:
> 
> 
> 
> On Sun, Jun 5, 2016 at 9:15 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
> 
>> On Jun 4, 2016, at 8:32 PM, vivek pandya <vivekvpandya at gmail.com <mailto:vivekvpandya at gmail.com>> wrote:
>> 
>> 
>> 
>> On Sun, Jun 5, 2016 at 8:56 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> 
>> > On Jun 4, 2016, at 7:56 PM, vivek pandya <vivekvpandya at gmail.com <mailto:vivekvpandya at gmail.com>> wrote:
>> >
>> > 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.

-- 
Mehdi



>  
> 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.
> 
> -- 
> Mehdi
> 
> 
> 
>> > 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.
>> 
>> 
>> --
>> Mehdi
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160604/f6180a28/attachment.html>