basic block missing after MachineInstr packetizing

Hi, all,

When I schedule machine instructions in a VLIW way and packetize them, a problem is encountered, and I will show it use a simplified case as follows.

############ original instruction sequence

insn1

jump LBB0_xx

LBB0_xx:

############ expected instruction sequence after scheduling and packetizing
insn1; jump LBB0_xx


LBB0_xx:

############ generated instruction sequence
insn1; jump LBB0_xx


#BB#xx:

BasicBlock BB#xx is commented out when insn1 and “jump LBB0_xx” is bundled.
I guess the reference to LBB0_xx is deconstructed when insn1 and LBB0_xx are packetized together thus BB#xx is commented out.

What should we do if the reference to LBB0_xx has to be maintained?

Thanks ahead!

Yang,

There is not enough info here to understand what is going wrong – what is your target? Is dependency dag correct going into scheduling and packetization?

Sergei

Sergei, Thank you for your attention.

My target is a custom VLIW DSP. I am not sure dependency dag is correct when it gets scheduled and packetized. Months ago, I submitted a bug at http://llvm.org/bugs/show_bug.cgi?id=17894 which explained more details.

I am not sure my understanding of this bug is proper, but modified my local codes this way and it works for my target when scheduling and packetizing.

Well why this problem does not occur for Hexagon target?

Regards.

Sergei, Thank you for your attention.

My target is a custom VLIW DSP. I am not sure dependency dag is correct when it gets scheduled and packetized. Months ago, I submitted a bug at http://llvm.org/bugs/show_bug.cgi?id=17894 which explained more details.

I am not sure my understanding of this bug is proper, but modified my local codes this way and it works for my target when scheduling and packetizing.

Well why this problem does not occur for Hexagon target?

FYI: if there is a bug in finalizeBundle() one possible fix is not calling it. Nothing in the MachineIR requires finalizeBundle to be called, bundles are perfectly valid without it. It is only there for legacy reasons because some targets want to see the extra BUNDLE marker with duplicate MachineOperands.

-Andy

Andy is right. There are different ways to “set” a bundle.

Why it does not happen to Hexagon – my guess would be that it could have been fixed locally, but has not been up streamed yet.

I am not sure dependency dag is correct when it gets scheduled and packetized

Without this, you cannot really expect scheduler or packetizer to do the right “thing”. Majority of problems I see in this code is from improper dependency information, so I suggest you try to figure this out first. If your local workaround would uncover some bigger issue, please update the bugzilla ticket.

Hope this somewhat helpful…

Sergei