Sorry, I dropped the ball on this one. On Mar 24, 2005, Ian Lance Taylor <ian@airs.com> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes: >> I realize the sequence construct is already taken for delayed >> branches, but that's only in the outermost insn pattern. We could >> overload the meaning, or just enclose the (sequence) in some other >> construct (a dummy parallel?), give it a different mode (a CC mode?) >> or something else to indicate that this is a combined pattern. Or >> create a different rtl code for cc0 sequences of instructions. The >> syntax is not all that important at this point. > I don't understand why you are suggesting a sequence at all. Why not > this: > (define_insn_and_split "cc0_condbranch_cmpsi" > [(set (pc) > (if_then_else (match_operator 3 "comparison_operator" > (match_operand:SI 0 "register_operand" "!*d*a*x,dax") > (match_operand:SI 1 "nonmemory_operand" "*0,daxi")))) > (label_ref (match_operand 2 "" "")) > (pc)))] > )] Because the above assumes the insn that sets cc is a single set, without anything else in parallel. If you have to handle parallels, you may be tempted to just add them to the combined insn, and then in some ugly cases you can end up having ambiguities. Consider a (clobber (reg X)) in parallel with the (set (cc)), for example. Consider that some instructions that use cc may also have such clobbers, and some don't, and that the clobber is the only difference between them. How would you deal with this? Consider, for the worst case, that whatever strategy you use to decide where to add the clobber is the strategy the port maintainer took when deciding where to add the explicit clobber to the two insn variants that use cc.q Besides, I feel the combined sequences might reduce the actual effects of the pattern explosion, since you won't have to generate code to match the whole thing and the components, you just match a sequence with the given components. But maybe it doesn't make any significant difference in this regard. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
