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

[vivek pandya via llvm-dev]

On Sun, Jun 5, 2016 at 10:16 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> 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> wrote:
>
>>
>> On Jun 4, 2016, at 8:32 PM, vivek pandya <vivekvpandya at gmail.com> wrote:
>>
>>
>>
>> On Sun, Jun 5, 2016 at 8:56 AM, Mehdi Amini <mehdi.amini at apple.com>
>> wrote:
>>
>>>
>>> > On Jun 4, 2016, at 7:56 PM, vivek pandya <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.
>
Sorry I didn't get that. Please elaborate.

>
> --
> 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/20160605/690a6533/attachment.html>