Re: [PATCH] Check STORE_FLAG_VALUE when expanding division by two.

[Andreas Schwab <schwab at suse dot de>]

Roger Sayle <roger@eyesopen.com> writes:

> As you're listed in MAINTAINERS as the m68k port maintainer, I wonder
> if I could ask your expertise on the following code sequences?

I'm not Jeff, but I can answer anyway.

> Currently mainline GCC generates the following for division by two:
>
> div2:   link.w %fp,#0
>         move.l 8(%fp),%d0
>         jbpl .L2
>         addq.l #1,%d0
> .L2:    asr.l #1,%d0
>         unlk %fp
>         rts
>
> The conditional branch and increment aren't explicitly represented in
> the RTL stream, but are output by m68k.c's "addsi_lshrsi_31" pattern.
> It looks like this pattern is intended purely to catch this division.
>
> My proposed patch to honour the target's STORE_FLAG_VALUE macro, causes
> GCC to instead generate the following:
>
> div2:   link.w %fp,#0
>         move.l 8(%fp),%d0
>         move.l %d0,%d1
>         add.l %d1,%d1
>         subx.l %d1,%d1
>         sub.l %d1,%d0
>         asr.l #1,%d0
>         unlk %fp
>         rts
>
> Which instead uses ashrsi_31 followed by subsi3.
>
>
> My guess, not being familiar with the m680x0 architecture, is that
> although the second sequence doesn't include a conditional branch, its
> probably slower than the original, thanks the the backends special pattern
> for exactly this case?

It depends. For the 68060 a not-predicted forward branch has a penalty of
7 cycles, which is more than the time to execute the additional insns in
the second sequence.  For all previous models, and also on the 68060 if
the branch is correctly predicted, the second sequence is always slower.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."