[llvm-commits] Patch for review: Speeding up ScheduleDAG computations

[Evan Cheng]

On Mar 6, 2008, at 5:28 AM, Roman Levenstein wrote:

> Hi Evan,
>
> 2008/3/5, Evan Cheng <evan.cheng at apple.com>:
>> I'm seeing 2 dejagnu test failures on my machine.
>>
>> CodeGen/Generic/print-arith-fp.ll
>> while running: llvm-as < /Users/echeng/LLVM/llvm/test/CodeGen/ 
>> Generic/
>> print-arith-fp.ll | llc
>> *** List scheduling failed! ***
>> SU(54): 0x120edc0: i32,ch,flag = CopyFromReg 0x120e680, 0x120b6a0,
>> 0x120e680:1
>>     0x12073e0: ch,flag = CALLpcrel32 0x1209aa0, 0x120eaf0
>>     0x120e680: ch,flag = ADJCALLSTACKUP 0x120f370, 0x120b100,
>> 0x12073e0, 0x12073e0:1
>>  has been released too many times!
>> Assertion failed: (0), function ReleasePred, file
>> ScheduleDAGRRList.cpp, line 213.
>
> OK. I can confirm this failure. I fixed it in the attached updated
> version of my patch (only the ScheduleDAGRRList patch is modified, the
> ScheduleDAGList patch is unaffected).

Ok, will test.

>
>
> There is still one moment, where I'm not quite sure, but in any case
> it is not worse than in the repository. It is related to Dan's comment
> about updates of PredSU->CycleBound in the CapturePred function. I
> inserted for now the following comment:
> // TODO: Check that PredSU is not in the AvailableQueue at this  
> moment!
> The problem is that currently there is no way to check if a node in
> the AvailableQueue, AFAIK. But if it is, then the node should be
> removed and inserted back into the queue to preserve the ordering. All
> tests compile without problems, but I'd still like to be sure that
> when this comment line is reached, the node is not in the queue.

There is a way. When a node is inserted into the AvailableQueue, the  
isAvailable field is set to true. Can you update the patch?

>
>
>
>> CodeGen/X86/2007-07-03-GR64ToVR64.ll
>
> OK. This one is not a real failure. Basically, the names of registers
> are swapped (see below), as far as I understand. Without my changes
> %rdi should be loaded into %mm1 and %rsi into %mm0.
>
>        .text
>        .align  16
>        .globl  foo
>        .type   foo, at function
> foo:
>        movd    %rdi, %mm0
>        movd    %rsi, %mm1
>        paddusw %mm1, %mm0
>        movq    %mm0, R
>        emms
>        ret
>        .size   foo, .-foo

Yes, that's silly. Please change the run lines to grep for movd and  
paddusw instead.

>
>
>> Are you seeing any issues?
>
> The same that you see. And some others related to the frontend, but
> they have nothing to do with this patch.
>
> Please, try again if possible and let me know if I can commit.

Will do.

Evan

>
>
> -Roman
>
>> On Mar 5, 2008, at 9:16 AM, Roman Levenstein wrote:
>>
>>
>>> 2008/3/5, Dan Gohman <gohman at apple.com>:
>>>> On Mar 4, 2008, at 3:56 AM, Roman Levenstein wrote:
>>>>>
>>>>
>>>>> make[5]: Entering directory
>>>>> `/opt/llvm.build/projects/llvm-test/SingleSource/UnitTests/Vector/
>>>>> SSE'
>>>>> make[5]: *** No rule to make target `Output/
>>>>> sse.expandfft.linked.rbc',
>>>>> needed by `Output/sse.expandfft.linked.bc'.  Stop.
>>>>
>>>>
>>>> When I've seen this error, the problem has been that my base llvm
>>>> build configure was run without an llvm-gcc in PATH.  llvm-test
>>>> apparently relies on the base llvm build to locate llvm-gcc for it.
>>>
>>> Thanks! Now I checked again and it seems to work.
>>>
>>> So, I have other questions about testing (I guess some of them are
>>> asked quite often ;-):
>>>
>>> 1) I do run llvm/test tests. At the end I get some figures about the
>>> number of PASSED and UNEXPECTEDLY FAILED tests. This is fine. But is
>>> it guaranteed that UNEXPECTEDLY FAILED are introduced by my code  
>>> or is
>>> it possible that due to some recent changes to the repository some  
>>> of
>>> those tests just fail? If it is due to the changes in the  
>>> repository,
>>> how do I know what are the figures without my changes, so that I can
>>> compare and see new failures introduced by my code? Are those  
>>> numbers
>>> published anywhere, may be in the nightly tests results??? Or  
>>> should I
>>> basically have to source trees: one for repository version and one  
>>> for
>>> my local modifications and then run tests under both trees?
>>>
>>> 2) If I run the llvm-test tests, how do I produce reports? How do I
>>> know that something failed?
>>>
>>> 3) How can I run only a selected subset of the tests from llvm-test?
>>>   In particular, I only change LLC mostly. Do I have to run the
>>> llvm-test every time, or can I reduce it to something smaller?
>>>
>>> Basically, I have my ScheduleDAG patches ready, All of the proposals
>>> from the review by you and Evan are implemented. But I don't know  
>>> how
>>> to test them properly using llvm tests and how can I understand if
>>> something is broken by them....
>>>
>>> I attach both patches for now, so that someone else can test them as
>>> well, while I'm trying to figure out how to do it on my machine.
>>>
>>> -Roman
>>> <
>>
>>> ScheduleDAGRRList
>>> .patch
>>>>
>>> < 
>>> ScheduleDAGList 
>>> .patch>_______________________________________________
>>
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
> < 
> ScheduleDAGRRList 
> .patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits