This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

Oleg Endo schrieb:

On Thu, 2012-08-23 at 19:52 +0200, Georg-Johann Lay wrote:
Uros Bizjak wrote:

This patch introduces TARGET_REJECT_COMBINED_INSN target hook, so
targets are able to reject combinations of two or more insns. The hook
is called from recog_for_combine, so it is the target that has the
final say on the combined insn.

great place for a hook, it was missing, IMO.

Just a note:  Wouldn't it be good to have a hook that may transform
a pattern to a new one and return that to combine?

As far as I understand that's what the splits during combine are for.

These patters are very specific. They only can map one set to two sets. It's not possible to implement a canonicalization for anything combine might come up with and that is just ready to be stuffed into recog.

However, I always get surprised when combine would actually take the
split and continue trying combinations with the insns that came out from
the split, and when it won't. Sometimes it works, sometimes it doesn't.
Very often I have to resort to insn_and_split, which is similar, but not
the same ...

The advantage is that you can da any transform in split1, even with new pseudos. The disadvantage is that the result does not get back into combine and that in split1 the meta-information om involved data is lost (zeroed bits etc.). At least that information is not available in insn condition or predicate.

However, there may be a pattern that does exactly the same thing
but is written down differently.  The backend then could try to
canonicalize the pattern before it goes into recog.

Do you mean something like already existing CANONICALIZE_COMPARISON macro? If so, then probably one would have to match/transform the patterns in C, which is not 'very nice', IMHO. Maybe relaxing the

Yes, it's a hook and in C. Sometime C can be more convenient.

For the hook in question, it would be the same effort as far as
the hook is concerned:  Ir really makes no difference if you

- Pass X to the hook and return true or false

- Pass X to the hook and return X or NULL_RTX.

However, the latter interface is much more general and powerful and
allows to change X -- or simply leave it alone like in
legitimize_address (target_legitimize_combine or so).

Some years ago there were plans for a define_combine thing for the
backend (similar to define_insn/split/expand/peephole etc.)
But that idea was dropped for some reason or in favor of a better or
easier approach.

combine-splitting (not insn_and_split, just define_split) would be
better for this?

RTL is great. I think it makes reading and writing back ends much more robust, easy and powerful. And I always wondered why there is no tree/SSA equivalent of RTL.

However, sometimes you are better off with C.

In any case, if combine doesn't try out all the combinations, then
something would have to do that in the backend and everything is back to
square one, except that every backend (sooner or later) will have some
kind of half-combine-half-recog implementation in it, won't it?

Yes, you are right. There is already too much recog-like code in the backends, for example in rtx_costs. In a private port I call recog from rtx_costs to get the costs from insn attributes. Works very nice and is much better to maintain than XEXP for many, many insns and patterns...

An other question is:

I always wondered if it is possible to transform code like

(set (reg:SI 0)
     (ior:SI (reg SI:1)
             (reg SI:2)))

or more complicated, combined patterns to a different pattern
if there is some additional knowledge.

For example, a backend may have an insn that can do the
combined operation efficiently, but only if reg2 is a
boolean value (0 or 1).

Currently you will have to write a combine pattern like

(set (reg:SI 0)
     (ior:SI (reg SI:1)
             (and:SI (reg SI:2)
                     (const_int 0))))


(set (reg:SI 0)
     (ior:SI (reg SI:1)
             (zero_extract:SI (reg:SI 2)
                              (const_int 1)
                              (const_int x)))))


(set (reg:SI 0)
     (ior:SI (reg SI:1)
             (and:SI (lshiftrt:SI (reg SI:2)
                                  (const_int x))
                     (const_int 1))))

You can imagine that it is really tedious to write
down all these patterns and describe their rtx_costs.

I think in this case one could define a predicate for those and then re-use it in multiple patterns.

Been there, done it: This needed yet another hook in find_reloads because you don't want to reload the whole predicate; you want to reload the individual operands. Therefore this needs a mapping from the predicate to its operands. Currently, reload has only magic for unary rtxes like zero_extract.

As for the costs, it would really be nice if it was possible to just
say: "If this pattern is matched, the total cost is X", instead of
partially re-implementing/describing the patterns in C in the rtx_costs
function.  I was already thinking of using recog functions in the
rtx_costs function, but I'm not sure whether it is the right thing to

Yes. Just call recog in combine :-) It needs some preparation, but "proof of concept" work is already done and works smooth in 45 and 4.6, and I don't see a reason why it should not work in newer versions. If you are interested I can explain the caveats and details.


I think one of the prime examples that would benefit from those things
are patterns to implement instructions such as bit-tests with constants
(on SH: tst #imm8,R0), where the basic pattern is simply:

(define_insn "tstsi_t"
  [(set (reg:SI T_REG)
	(eq:SI (and:SI (match_operand:SI 0 "logical_operand" "%z,r")
		       (match_operand:SI 1 "logical_operand" "K08,r"))
	       (const_int 0)))]

.. but then 9 variations are required to make it really work under
various circumstances.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]