This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook
Uros Bizjak schrieb:
On Thu, Aug 23, 2012 at 10:46 PM, Georg-Johann Lay <firstname.lastname@example.org> wrote:
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).
I did some experiments with your proposal, but it is not as simple as
it is written above. We use existing insn as a testing place, where we
stuff various combinations and call recog. After all processing, we
have to restore insn to its original state and singal
recog_for_combine caller that we recognized the combination, but with
optional clobbers. So, calling sites only expect the
confirmation/rejection of the proposed patterns, and in case of
confirmation, recog_for_combine is allowed to decorate the pattern
with optional clobbers.
If I understand you correctly, problems would arise if such a hook
produced a pattern that is *not* recognized. In such a case combine
performs a roll-back, and with a changed pattern some assumptions
Are there also problems if the hook transformed to a pattern that
is known to be recognized? Like "I know this pattern, just
canonicalize it to an expression that will match". In that case
no roll-back is needed.
Your proposal that recog_for_combine changes the pattern is not what
callers expect from this function. Probably, there are better places
to implement target-dependent transformations, and leave
recog_for_combine just the task to confirm that them combined pattern
Yes in an ideal world such a hook/transformation would not be
needed and combine could perform all the magic.
combine is a very powerful pass to cook up new instructions out
of the blue, but unfortunately there are some shortcomings that
cannot be worked around in a backend.
One example is the problem of intermediate insn to reach a
complex insn. Another problem is that combine does not try
everything. It's greedy to generate and try PARALLELs, but for
ordinary arithmetic it misses to cook up valid combination even
if they are within combine's limited complexity.