This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A plan for eliminating cc0
- From: Paul Schlie <schlie at comcast dot net>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Fri, 25 Mar 2005 17:54:52 -0500
- Subject: Re: A plan for eliminating cc0
> 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-