llvm dev - Oct 2012 - [LLVMdev] Problem with PostRASchedulerList.cpp - advice wanted

When you compile the attached file using

  llc -march=x86 -mcpu=atom sched-bug.ll -o -

The Post-RA scheduler changes the sequence

movl %ecx, (%esp)
     bsfl (%esp),%eax # this came from inline assembly code

to read

               bsfl (%esp),%eax # this came from inline assembly code
movl %ecx, (%esp)

This is an incorrect schedule, because it seems the scheduler is not aware that
the memory load by the bsfl depends on  the memory store by the movl.

If you are familiar with the Post-RA scheduler works, then I would appreciate
any suggestions you might have as to how I could fix this problem, such as by
treating inline assembly code as a barrier or by including memory references in
scheduling decisions.

Thanks,

Preston G

--
Preston Gurd <preston.gurd at intel.com>
  Intel Waterloo

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121017/0ef31365/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sched-bug.ll
Type: application/octet-stream
Size: 234 bytes
Desc: sched-bug.ll
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121017/0ef31365/attachment.obj>

Preston, 

 

If it is not in itself obvious.  With somewhat high degree of certainty you
need to look at the scheduling DAG going into the Post-RA scheduler. If
these two SUs do not have a chain edge between them, scheduler is free to
reorder them.

Why they do not have an edge - it could be a number of reasons - from AA
telling dag constructor so, to a bug in the dag construction logic. Hope
this does not sound too trivial J

 

Sergei

 

---

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Gurd, Preston
Sent: Wednesday, October 17, 2012 5:34 PM
To: LLVMdev (LLVMdev at cs.uiuc.edu)
Subject: [LLVMdev] Problem with PostRASchedulerList.cpp - advice wanted

 

When you compile the attached file using

 

  llc -march=x86 -mcpu=atom sched-bug.ll -o -

 

The Post-RA scheduler changes the sequence

 

movl %ecx, (%esp)

     bsfl (%esp),%eax # this came from inline assembly code

 

to read

 

               bsfl (%esp),%eax # this came from inline assembly code

movl %ecx, (%esp)

 

This is an incorrect schedule, because it seems the scheduler is not aware
that the memory load by the bsfl depends on  the memory store by the movl. 

 

If you are familiar with the Post-RA scheduler works, then I would
appreciate any suggestions you might have as to how I could fix this
problem, such as by treating inline assembly code as a barrier or by
including memory references in scheduling decisions.

 

Thanks,

 

Preston G

 

--

Preston Gurd <preston.gurd at intel.com>

  Intel Waterloo

 

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

On Oct 17, 2012, at 3:33 PM, "Gurd, Preston" <preston.gurd at
intel.com> wrote:
> When you compile the attached file using
>  
>   llc -march=x86 -mcpu=atom sched-bug.ll -o –
>  
> The Post-RA scheduler changes the sequence
>  
> movl %ecx, (%esp)
>      bsfl (%esp),%eax # this came from inline assembly code
>  
> to read
>  
>                bsfl (%esp),%eax # this came from inline assembly code
> movl %ecx, (%esp)
>  
> This is an incorrect schedule, because it seems the scheduler is not aware
that the memory load by the bsfl depends on  the memory store by the movl.
>  
> If you are familiar with the Post-RA scheduler works, then I would
appreciate any suggestions you might have as to how I could fix this problem,
such as by treating inline assembly code as a barrier or by including memory
references in scheduling decisions.
>  
Hi Preston,

Someone pointed me to a bug filed for this: http://llvm.org/PR13504.

Maybe you can add a memory clobber as a workaround.

-Andy

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