> Richard Henderson <rth at redhat dot com>
>> Ian Lance Taylor wrote:
>> OK, here is a different approach toward eliminating cc0, based on a
>> combination of my earlier proposal and what Alex described.  I'm
>> looking for comments from anybody.
>
> One potential problem: once the NOTICE_UPDATE_CC pass is done, we
> can no longer run *any* pass that reorders code, because we're
> left with
> 
>        [(set (reg 1) (plus (reg 1) (reg 2)))
>         (clobber (reg cc_reg))]
>
>        [(set (pc) (if_then_else (lt (reg cc_reg) 0)
>                        (label 1)
>                        (label 2)))]
>
> Note that there's no longer any insn that *sets* cc_reg.  I think
> that's a bit dangerous.
> 
> One solution to this is to convert the new setter to
>
>         [(set (reg 1) (plus (reg 1) (reg 2)))
>          (set (reg cc_reg) (unspec [(const_int 0)] cc_set))]
> 
> I don't think it matters what we set cc_reg to, just that *some*
> set is visible in the instruction stream.

This feels like a reasonable philosophical approach; but would seem more
ideal if dependant cc-states* could be defined as being more explicitly
dependant on either this instruction's set register value, or it's source
expression; thereby allowing potential future multi-set aware optimizations
to optimize such instructions more intelligently without having to re-author
their descriptions again. Possibly via a macro enabling target descriptions
of the form:

      [(set ((reg %0) (cc-cmp) (cc-carry) ...) (<some-rtl-operation> ...))]

Which could expand into whatever deemed most ideal at the time, with the
goal to enable intelligent multi-set instruction optimization, at least in
the case were all multi-set targets are all logically dependant on the same
value state.

(cc-states*: given that it would be ideal to be able to specify that one
 type of instruction may alter or depend on a particular cc-state, but not
 others; thereby enabling the specification of ISA's which may have multiple
 logical state regs which may be set in parallel, which subsequent
 instructions may be independently dependant on; thereby nicely generalizing
 the specification of global state instruction result dependencies.)


Reply via email to