newppc-branch: Some problems

[Clinton Popetz]

On Thu, Feb 17, 2000 at 09:47:37AM -0600, Clinton Popetz wrote:
> On Thu, Feb 17, 2000 at 04:27:20PM +0100, Franz Sirl wrote:
> > Hi,
> > 
> > /tmp/ccV46BSr.s: Assembler messages:
> > /tmp/ccV46BSr.s:1923: Error: Symbol .LCG74 already defined.
> > /tmp/ccV46BSr.s:1941: Error: Symbol .LCG75 already defined.
> > /tmp/ccV46BSr.s:1951: Error: Symbol .LCG76 already defined.
> > /tmp/ccV46BSr.s:1962: Error: Symbol .LCG77 already defined.
> 
>  
> > There's definitely something fishy going on with the tree-based inlining on 
> > PPC, as I already had problems with it in the normal branch. Clinton looked 
> > a little bit at this problem, maybe he already knows more about it.
> 
> I know the symptom but not the cure.  Inlining is causing some exception
> region to be copied, with the code from builtin_setjmp_receiver being
> duplicated in two spots, and this means the label emitted by 
> rs6000_emit_load_toc_table is appearing twice.  I'll look at it again today.


This isn't actually tree-based inlining bug.  If we do integration on a
load_toc_v4_PIC_1b insn, the rtl looks like:

(insn 46 45 48 (parallel[ 
            (set (reg:SI 84)
                (symbol_ref:SI ("*.LCG0")))
            (unspec[ 
                    (symbol_ref:SI ("*.LCG0"))
                    (symbol_ref:SI ("*.LCTOC1"))
                ]  6)
        ] ) -1 (nil)
    (nil))

Since those symbols aren't in the constant pool, copy_rtx_and_substitute will
assume they are safe to copy into in the calling function.  But this insn 
outputs:

        bl .LCG0         # 48   load_toc_v4_PIC_1b      [length = 8]
        .long .LCTOC1-.LCG0+4
.LCG0:

And then we get two copies of LCG0.  One solution would be to have
load_toc_v4_PIC_1b make its own label unique at output time, instead of having
rs6000_emit_load_toc_table try to keep it unique.  If that sounds reasonable,
I'll submit a patch.

					-Clint