Re: Fix for GCC Bugzilla Bug 36133

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Wed, 25 Jun 2008, Andreas Schwab wrote:
(This ^ much behind on mailing lists.  Whee.)

> "Gunnar Von Boehn" <gunnar@genesi-usa.com> writes:
>
> > Maybe I can summarize the question again.
> > When I understood your question correctly then it was:
> > "Does it make sense to mark the CC as invalid after a shift instruction."
> > Your point was that a shift will "trash" the carry flag.
> > If the CC is marked as valid GCC will but BCC instructions after the shift.
> > If the CC is marked as invalid then GCC will put a TST before the BCC
> > instruction to regenerate the conditions codes.
>
> You need to argue on the RTL insns that can be generated.  I cannot
> prove that there will never be a bgtu/bltu insn following the lshiftr
> insn.  If that can happen your change would introduce a wrong-code bug.
>
> In any case, the right place to change that is in notice_update_cc
> anyway.

Despite rth's "???" there *is* an almost-pre-packaged way:
"set cc_status.flags |= CC_NO_OVERFLOW" for those insns in
notice_update_cc (right, invalidating use of carry *and*
overflow, but in practive, no difference).

See the CRIS port (another cc0 target where most insns touch
cc0), where I use the insn attribute noov32 (because CRIS v32
behaves differently) which is tested in NOTICE_UPDATE_CC to
check that the carry is valid, setting CC_NO_OVERFLOW there if
not.

brgds, H-P