On Sat, Aug 25, 2012 at 11:55 AM, Georg-Johann Lay <a...@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? Yes, please see the code after validate_replacement: label in combine.c where it it assumed that recog_for_combine strips clobbers on the failure (or adds unknown number of clobbers on success). You will see that various more or less complex transformations happen after this label using SUBST and SUBST_MODE macros. On the failure, the combined pattern is changed/transformed in some way and recog_for_combine is called again. If recognition fails, another transformation takes place, etc... > 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. For the hook - yes, since the pattern will be changed in a way that is not expected by code that calls recog_for_combine. Your proposed transformation should happen after validate_replacement: label. However, this change is out of the scope of my proposed patch, this feature is not related to the ability to reject invalid insns. BTW: The calling code expects recog_for_combine to strip clobbers from the tested combined pattern on failure. This was not the case in my patch, so please expect v2 shortly. Uros.
