llvm dev - Oct 2011 - [LLVMdev] Live code elimination problem in code generation

Hello. :)

I've met a problem that eliminates a live code in code generation phase.

The initially generated code is shown as follows (as a pseudo code):
( Before pseudo-code expansion. )

----------
loop:
  :
  :
  set P0 <- xxx ( P0: a physical register for a parameter of function F )
  set P1 <- yyy ( P1: a physical register for a parameter of function F )
  SELECT_CC z1, z2, z3, ...
      ( <- I don't know why this is scheduled at this time,
            however it is independent from function F )
  call F
  :
  :
----------

After that, pseudo code expansion stage expands SELECT_CC by slicing the
machine basic clock.

----------
loop:
  :
  :
  set P0 <- xxx ( P0: a physical register for a parameter of function F )
  set P1 <- yyy ( P1: a physical register for a parameter of function F )
  :
  branch_cond B2, B3
B2:
  mov v1, v2, v3
B3:
  call F
  :
  :
----------

At first,
the dead code elimination stage misthinks P0 and P1 is not alive
since the live variable analysis (actually it seems as a live physical
register analysis)
in DCE stage is somewhat wrong (to my thinking).
Therefore, set Px statements are all eliminated.
Then I modified the DCE code to keep the live physical register information
in each MBB.
But they are eliminated in some other optimization stage.

To my thinking, the initial placement of SELECT_CC seems wrong.
I tried to dig in SelectionDAG directory, I could find any clue.

How can I avoid this situation ?
Anyone can give me a hint ?


Thank you.
Have a nice day!



Regards,
Hae-woo Park
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111015/095def2e/attachment.html>

On Oct 14, 2011, at 9:04 PM, Hae-woo Park wrote:
> I've met a problem that eliminates a live code in code generation
phase.
> 
> The initially generated code is shown as follows (as a pseudo code):
> ( Before pseudo-code expansion. )
> 
> ----------
> loop:
>   :
>   :
>   set P0 <- xxx ( P0: a physical register for a parameter of function F
)
>   set P1 <- yyy ( P1: a physical register for a parameter of function F
)
>   SELECT_CC z1, z2, z3, ...
>       ( <- I don't know why this is scheduled at this time,
>             however it is independent from function F )
>   call F
>   :
>   :
> ----------
> 
> After that, pseudo code expansion stage expands SELECT_CC by slicing the
machine basic clock.
I assume you have your own target? I haven't seen this happening with one of
the standard targets.

Your analysis is correct, SELECT_CC shouldn't be scheduled there.

Normally, LowerCall will create glue edges between the copyToReg SelectionDAG
nodes and the CALL node. Is your target not doing that?

/jakob

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

Dear Oleson,

Due to your help, I found the bug in my own target.
I missed out a glue option of the JumpLink instruction in my InstrInfo.td.

Thank you so much ! :)



Hae-woo Park




2011/10/15 Jakob Stoklund Olesen <stoklund at 2pi.dk>
>
> On Oct 14, 2011, at 9:04 PM, Hae-woo Park wrote:
>
> I've met a problem that eliminates a live code in code generation
phase.
>
> The initially generated code is shown as follows (as a pseudo code):
> ( Before pseudo-code expansion. )
>
> ----------
> loop:
>   :
>   :
>   set P0 <- xxx ( P0: a physical register for a parameter of function F
)
>   set P1 <- yyy ( P1: a physical register for a parameter of function F
)
>   SELECT_CC z1, z2, z3, ...
>       ( <- I don't know why this is scheduled at this time,
>             however it is independent from function F )
>   call F
>   :
>   :
> ----------
>
> After that, pseudo code expansion stage expands SELECT_CC by slicing the
> machine basic clock.
>
>
> I assume you have your own target? I haven't seen this happening with
one
> of the standard targets.
>
> Your analysis is correct, SELECT_CC shouldn't be scheduled there.
>
> Normally, LowerCall will create glue edges between the copyToReg
> SelectionDAG nodes and the CALL node. Is your target not doing that?
>
> /jakob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111017/841303e9/attachment.html>