Re: Suggestion for a fix to Bug middle-end/20177

[Paul Schlie <schlie at comcast dot net>]

> Steven Bosscher wrote:
>> Mostafa Hagog <MUSTAFA@il.ibm.com> wrote:
>> This is interesting, so there could be cases were want to copy CC
>> register when doing SMS.  what happens if we want to move the set
>> of a CC to another iteration of the loop ? or the use of the CC ?  but
>> usually this is couldn't happen in a simple loop, right? the use of CC
>> is eventually used in a branch, or there is something that I am missing ?
>
> IIRC these notes are for CCO, and you have to move the CC setter
> and user together.

- unless it can be guaranteed that the particular setter's cc, will be
  preserved (i.e. not corrupted by successive operations) prior to it's
  ultimate use; or alternatively regenerating the setter's cc typically
  by comparing it's previously computed data result with 0 (to regenerate
  the cc side effect, not necessarily the operation), if the user is moved
  past potentially corrupting successive operations; it would seem?

> Actually I think SMS for CC0 targets is Just Silly to do at all ;-)

- with the exception that it should be useful to eliminate otherwise
  unnecessary explicit comparison operations if an otherwise required
  operation (with the the desired setter cc side effects) can be more
  optimally scheduled immediately prior to a user of it's cc side
  effect (as is often typically the case when a conditional branch is
  dependant on a previously computed result being compared against 0).

  (but agree that as cc0 targets tend to be lightly pipelined in-order
   issue and completion machines, they tend to not be highly sensitive to
   instruction ordering; with the exception of conditional branching code
   does typically benefit from ideally scheduled sequences which do not
   require the re-synthesis of a cc through the use of an explicit
   comparison (or likely worse, a saved cc register) operation; which a
   good schedule would tend to likely avoid if possible; I'd guess.)