This is the mail archive of the gcc-patches@gcc.gnu.org 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


Uros Bizjak schrieb:
On Thu, Aug 23, 2012 at 10:46 PM, Georg-Johann Lay <avr@gjlay.de> 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 will break?

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
is OK.

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.

Johann


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