Re: A plan for eliminating cc0

[Paul Schlie <schlie at comcast dot net>]

> From: Ian Lance Taylor <ian@airs.com>
>> Paul Schlie <schlie@comcast.net> writes:
>> Thereby enabling something like:
>> 
>> (insn xxx [(set (reg: A) (xxx: (reg: B) (reg: C)))
>>            (set (reg: CC) (newly-set-reg: A))
>>           ....)
>> 
>> (insn branch-equal (set (pc) (if_then_else
>>                                (ge: CC 0)
>>                                (label_ref 23)
>>                                (pc)))
>>                     ...)
>> 
> Yes, a backend could be implemented this way.  There are two problems.
> 
> 1) Many of the optimizers analyze instructions by first calling
>    single_set and working with the results of that.  For example,
>    combine won't work with any insn for which single_set returns NULL.
>    And single_set will normally return NULL for your insn xxx above.

- As leading edge processor architectures seem to be slowly increasing
  intra-instruction level parallelism (i.e. backing slowly away from a
  pure simple one-operation/one-instruction RISC ISA, toward enabling a
  single instruction to potentially operate on a small set of operands
  which my yield multiple, non-interdependent results simultaneously
  (i.e. results dependant on only on the operands).  Are there any
  plans to eliminate this "single-set" restricting presumption, thereby
  enabling the potential optimization of multi-operand/operation/result
  instruction sequences?

- However regardless, although the above represents a primitive example
  of intra-instruction level multi-operation/result parallelism; I wonder
  if it's restricted enough case that optimization may be simply enabled
  for all instructions which have a "single-live-set"?

  In other words, although I understand parallel instruction optimization
  may be beyond the capabilities of many of the present optimizers, it
  seems "safe" to enable optimization of the "live" path, which would be
  the case when only a "single-set" has live dependencies, and the remaining
  "set(s)" are are "dead" (i.e. have no dependants), therefore irrelevant?

  Which would seem to be the most likely the case when a second parallel
  "set" is used to specify an update to a global condition-state, as most
  updates won't likely have conditional branch dependants? (Therefore safe
  to optimize the data-path, or in cases when the data path is dead,
  implying the condition-state path may be optimized irrespective of the
  data path.  Which would be analogous to turning a subtract into a compare
  instruction when the result of the subtract isn't used other than as
  required to set the global condition-state.)
  
> 2) Reload requires the ability to insert arbitrary instructions
>    between any pair of instructions.  The instructions inserted by
>    reload will load registers from memory, store registers to memory,
>    and possibly, depending on the port, move values between different
>    classes of registers and add constants to base registers.  If
>    reload can't do that without affecting the dependencies between
>    instructions, then it will break.  And I don't think reload will be
>    able to do that between your two instructions above, on a typical
>    cc0 machine in which every move affects the condition codes.

- Understood, however along a similar line of though; it would seem "safe"
  to simply "save/restore" the global condition-state around all potentially
  destructive memory operations.

  Which at first glance may seem excessive, however observing that most
  frequently required simple load/store operations on most targets won't
  modify global condition-state; and in the circumstances when more complex
  operations which may modify it are required, it need only be save/restored
  if it has dependants. Which as observed above, won't likely typically be
  the case.

  So overall it appears that there's likely very little effective overhead
  making all memory transactions effectively transparent to the global
  condition-state when it matters, as global condition-state will only be
  required to saved/restored in the likely few circumstances when a complex
  memory transaction may modify it, and it has dependants?

  (does that seem rational? or may I be missing something fundamental?)

thanks again, -paul-