> Björn Haase <[EMAIL PROTECTED]> writes:
> I have thinking about how to overcome part of the "double-setter"
> difficulties that arise when implementing cc0->CCmode conversion for
> a couple of targets:
> IIUC correctly one of the two or three difficulties with cc0->CCmode
> conversion is, that combine in it's present form is not able to
> recognize that in a sequence like
>
> (parallel[
> (set reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102))
> (set reg:CC_xxx CC) (compare (reg:SI 101) (reg:SI 102)))])
> ((set reg:CC_xxx CC) (compare (reg:SI 101) (reg:SI 102)))
>
> the compare instruction could be avoided. IIUC it is presently suggested
> to make use of *many* peephole2 patterns for solving this problem.
- I wonder if this makes any sense, as it seems that if instructions
specified their factual behavior, including their condition code side
effects, then for example: (assuming xC mode represents an x-sized
condition result vs. a generic CC sized result, and specifying no-op
instructions to glue together CC-side effects with their use):
(sub:SI
(set (reg:SI %0) (minus:SI (reg:SI %1) (reg:SI %2)))
(set (reg:SC %0) (compare (reg:SI %1) (reg:SI %2)))
"code")
(xor:SI
(set (reg:SI %0) (xor:SI (reg:SI %1) (reg:SI %2)))
(set (reg:QC %0) (compare (subreg:QI %1 0) (subreg:QI %2 0)))
"code")
(cmp:SC
(set (reg:CC EQ) (compare (reg:SI %0) (reg:SI %1)))
"code")
(nop:SC ; equate the CC with an SC pseudo.
(set (reg:CC EQ) (reg:SC %0))
"")
(nop:SZ ; equate CC with both SI pseudo == 0, and SC pseudo.
(def (compare (reg:SI %0) (const 0)) (reg:SC %0)))
(set (reg:CC EQ) (compare (reg:SI %0) (const 0)))
"")
(jmp:EQ
(set (pc) (if_then_else (reg:CC EQ) (label) (label)))
"code")
Where nop:SC/SZ generates no code, and only exist to aid CC matching.
- Then some program code like hypothetically this:
(set (reg:SI 100) (xor:SI (reg:SI 101) (reg:SI 102)))
(set (pc) (if_then_else (compare (reg:SI 101) (reg:SI 102))
(label) (label)))
Would match/generate:
(xor:SI (set (reg:SI 100) (xor:SI (reg:SI 101) (reg:SI 102))
(set (reg:CC 100) (compare (subreg:QI 101 0) (subreg:QI 102 0))))
(cmp:SC (set (reg:CC EQ) (compare (reg:SI 101) (reg:SI 102))))
(jmp:EQ (set (pc) (if_then_else (reg:CC EQ) (label) (label)))
- Or program code like:
(set (reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102)))
(set (pc) (if_then_else (compare (reg:SI 101) (reg:SI 102))
(label) (label)))
Would match/generate:
(sub:SI (set (reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102)))
(set (reg:SC 100) (compare (reg:SI 101) (reg:SI 102))))
(nop:SC (set (reg:CC EQ) (reg:SC 100)))
(jmp:EQ (set (pc) (if_then_else (reg:CC EQ) (label) (label)))
- Or program code like: (when based on a result comparison to zero)
(set (reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102)))
(set (pc) (if_then_else (compare (reg:SI 100) (const 0)) (label) (label)))
Would simply match/generate:
(sub:SI (set (reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102)))
(set (reg:SC 100) (compare (reg:SI 101) (reg:SI 102))))
(nop:SZ (def (compare (reg:SI 100) (const 0)) (reg:SC 100)))
(set (reg:CC EQ) (compare (reg:SI 100) (const 0))))
(jmp:EQ (set (pc) (if_then_else (reg:CC EQ) (label) (label)))
- Which requires no peep-holes, as nop:SC/SZ effectively act as glue
guiding the optimal use of cc-side effects as required for good code.
(as just a though, does this seem potentially reasonable?)
