Jeff Law writes:
> > * cse.c (fold_rtx) <second case CC0>: If prev_insn_cc0 is NULL
> > don't call equiv_constant on it.
> I can't help but feel something different needs to be done here. It's
> always been the case that those two insns are expected to be contiguous
> and there's going to be code all over the place that makes that
> assumption and that model is what every GCC developer has expected for
> the last 20+ years.
>
> What precisely about Richi's patch causes the setter and user to end up
> in different blocks? I'm guessing we now consider the comparison itself
> as potentially trapping and thus we end the block immediately? The
> consumer then appears in the next block?
Yes, r180192 makes tree-eh.c (stmt_could_throw_1_p) dive further into
the expression, apparently finding a potentially trapping FP comparison,
which causes the code generation difference.
gcc-4.5 generated:
.type _Z1ff, @function
_Z1ff:
.LFB0:
.cfi_startproc
link.w %fp,#0
.cfi_def_cfa 14, 8
ftst.s 8(%fp)
fsge %d0
extb.l %d0
neg.l %d0
unlk %fp
.cfi_offset 14, -8
rts
.cfi_endproc
while gcc >= 4.7 (with the ICE-preventing patch applied) generate:
.type _Z1ff, @function
_Z1ff:
.LFB0:
.cfi_startproc
.cfi_personality 0,__gxx_personality_v0
.cfi_lsda 0,.LLSDA0
link.w %fp,#0
.cfi_offset 14, -8
.cfi_def_cfa 14, 8
.LEHB0:
.LEHE0:
.LEHB1:
ftst.s 8(%fp)
.LEHE1:
fsge %d0
neg.b %d0
and.l #255,%d0
jra .L1
.L3:
move.l %d0,-(%sp)
jsr __cxa_begin_catch
addq.l #4,%sp
.LEHB2:
jsr __cxa_end_catch
.L1:
.LEHE2:
unlk %fp
rts
.cfi_endproc
plus a lot of exception table data. (Note the label before the 'fsge'.)
> Alternately (and probably better)
> would be to convert the remaining stragglers and drop the old cc0
> support entirely.
I'd love to see that happen, but it would take someone like me a lot of time
to complete. (I did try an incremental conversion of just the FP stuff 2-3
years ago, but it didn't work well. Now I'd probably rewrite m68k.md and
everything cc0-related in m68k.c from scratch.)
/Mikael
