This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook
On Thu, 2012-08-23 at 22:46 +0200, Georg-Johann Lay wrote:
>
> > 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.
Yes, that's what I meant by 'which is similar, but not the same ...'
> 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.
True.
> 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...
Yep, that's what I meant by 'have to match/transform the
patterns in C, which is not very nice'.
> Been there, done it: http://gcc.gnu.org/ml/gcc/2010-11/msg00222.html
> 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.
I see. Thanks for the pointers.
> 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.
Yes, I am very much interested indeed. Please do carry on (either on
the list or in private) :)
Wouldn't it somehow make sense to establish a 'standard' way of doing
this kind of thing (getting insn costs from attributes) for all
backends? As an option of course, not requiring every backend to do it
that way from day one.
Cheers,
Oleg