Re: A plan for eliminating cc0

[Ian Lance Taylor <ian at airs dot com>]

Paul Schlie <schlie@comcast.net> writes:

> > 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?

I'm not aware of any particular plans to eliminate the single_set
presumption.  I think that there is a general awareness that it is an
issue, but I don't know of any general agreement on how serious it is
or how difficult it would be to change.

I'm also not aware of processors changing as you describe, except for
the particular special case of SIMD vector instructions.  gcc can and
does represent vector instructions as a single set.

> - 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?

Yes, that is how it works today.  A parallel set in which all but one
of the results is dead counts as a single set.  See the code in
rtlanal.c.

>   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.)

Yes, but the point of representing changes to the condition flags is
precisely to permit optimizations when the condition flags are used,
and that is precisely when the single_set assumption will fail.  You
are correct that in general adding descriptions of the condition code
changes to the RTL won't inhibit optimizations that don't meaningfully
set the condition code flags.  But it will inhibit optimizations which
do set the condition code flags, and that more or less obviates the
whole point of representing the condition code setting in the first
place.

> > 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.

Safe but very costly.  It assumes that every processor has a cheap way
to save and restore the condition codes in user mode, which is not
necessarily the case.  And it assumes that the save and restore can be
removed when not required, which is not obvious to me.

>   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.

On machines which currently use cc0, which are the only machines under
discussion here, simple load/store operations do modify global
condition state.

Ian