search for: isblockonlyreachablebyfallthrough

...ay slots, I get: Is this with the latest SVN HEAD version of LLVM or some other version? The delay slot filler and many other things have been updated for the Microblaze backend. In particular, the commit r120095 for the MBlaze backend fixed some issues with missing block labels due to AsmPrinter::isBlockOnlyReachableByFallthrough not taking into account delay slots in basic blocks. > My question is, why would inserting a NOP or splicing an instruction in > a MachineBasicBlock cause a label to go missing? Could someone point me > to appropriate places to look? The problem is that AsmPrinter::isBlockOnlyReachable...

The Sparc, Microblaze, and Mips code generators implement branch delay slots. They all seem to exhibit the same bug, which is not surprising since the code is very similar. If I compile code with this snippit: while (n--) *s++ = (char) c; I get this (for the Microblaze): swi r19, r1, 0 add r3, r0, r0 cmp r3, r3, r7 beqid r3,

...he asmprinter is a simple pass through that doesn't look at the code, which isOnlyReachableByFallthrough violates. > > As far as a proposed solution, since asmprinter is the only user of isOnlyReachableByFallthrough, I'd recommend moving isOnlyReachableByFallthrough to be AsmPrinter::IsBlockOnlyReachableByFallthrough. Then you can make it virtual, and have the sparc backend provide its own implementation of it (which might as well just return false all the time). Sounds reasonable to me. The attached llvm-sparc-asmprinter1.patch implements what you've described above, with SparcAsmPrinter::isBlockOnlyReac...

...the asmprinter is a simple pass through that doesn't look at the code, which isOnlyReachableByFallthrough violates. As far as a proposed solution, since asmprinter is the only user of isOnlyReachableByFallthrough, I'd recommend moving isOnlyReachableByFallthrough to be AsmPrinter::IsBlockOnlyReachableByFallthrough. Then you can make it virtual, and have the sparc backend provide its own implementation of it (which might as well just return false all the time). > and if so would something like > > BB#7: > ... > BCOND cond1, BB#8 > BCOND cond2, BB#57 > BB#8: > ... >...

...I get: > > Is this with the latest SVN HEAD version of LLVM or some other version? The delay slot filler and many other things have been updated for the Microblaze backend. In particular, the commit r120095 for the MBlaze backend fixed some issues with missing block labels due to AsmPrinter::isBlockOnlyReachableByFallthrough not taking into account delay slots in basic blocks. > [snip] Thanks Wesley! I'm currently using r119910. I'll update. -Rich

On 11/12/2009, at 10:43 AM, Anton Korobeynikov wrote: > Hi, Chris > >> That is target independent code, so you should not put sparc specific changes there. It sounds like one of the sparc-specific target hooks is wrong. > Since sparc does not provide any hooks for operation of branches (e.g. > AnalyzeBranch and friends) it might be possible that generic codegen > code is

...rinter is a simple pass through that doesn't look at the code, which isOnlyReachableByFallthrough violates. >> >> As far as a proposed solution, since asmprinter is the only user of isOnlyReachableByFallthrough, I'd recommend moving isOnlyReachableByFallthrough to be AsmPrinter::IsBlockOnlyReachableByFallthrough. Then you can make it virtual, and have the sparc backend provide its own implementation of it (which might as well just return false all the time). >> > > Sounds reasonable to me. The attached llvm-sparc-asmprinter1.patch implements what you've described above, with SparcAsmP...

>  I suspect this is a straight forward problem so I thought I'd ask. > I'm developing a new backend.  I recently updated from the LLVM > repository and now my output assembly is branching to labels/blocks that > have been removed.  It had been working fine two weeks ago.  What looks > suspicious is the following message: Just quick though: have you implemented the

...>> >> Is this with the latest SVN HEAD version of LLVM or some other version? The delay slot filler and many other things have been updated for the Microblaze backend. In particular, the commit r120095 for the MBlaze backend fixed some issues with missing block labels due to AsmPrinter::isBlockOnlyReachableByFallthrough not taking into account delay slots in basic blocks. >> > [snip] > > Thanks Wesley! I'm currently using r119910. I'll update. > > -Rich Wesley, You changes work for me also. I applied something similar to the Mips CG and they worked there also. Thanks again. -Rich

I suspect this is a straight forward problem so I thought I'd ask. I'm developing a new backend. I recently updated from the LLVM repository and now my output assembly is branching to labels/blocks that have been removed. It had been working fine two weeks ago. What looks suspicious is the following message: TryTailMergeBlocks: BB#1, BB#3, BB#4 Looking for common tails of

Hi, Chris > That is target independent code, so you should not put sparc specific changes there.  It sounds like one of the sparc-specific target hooks is wrong. Since sparc does not provide any hooks for operation of branches (e.g. AnalyzeBranch and friends) it might be possible that generic codegen code is broken in absence of these hooks. -- With best regards, Anton Korobeynikov Faculty