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

[Roman Levenstein]

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

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.


>  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

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

-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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScheduleDAGRRList.patch
Type: text/x-diff
Size: 5390 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20080306/635c6aef/attachment.patch>