On Tue, Feb 7, 2012 at 11:48 AM, Richard Guenther <richard.guent...@gmail.com> wrote:
>>>> (BTW: I think that the change to combine.c would be nice to have, to >>>> find more other combine opportunities. I will propose the patch >>>> separately.) >>> >>> Shouldn't there be a canonical order for parallels throughout the whole >>> compiler? Maybe just enforced by gen_rtx_PARALLEL / RTL checking? >>> At least as far as I understand "execution order" of insns inside a PARALLEL >>> is undefined. >> >> All operations inside parallel happen "at the same time". And there is >> no canonical order enforced, as sadly shown by the discrepancy between >> combine and compare elimination passes. > > Sure - all what I say is that the fix should be to enforce such canonical > order instead of dealing with both. rth proposed to adopt new scheme to change combine.c. However, I don't think this is a good idea, since it would mean "fixing" many existing in-tree and out-of-tree targets. OTOH, I thought that swapping operands in combine would also benefit other parts of the compiler, namely load/store multiple patterns, maybe swap insns, and similar. It was also fairly easy to teach combine to handle both approaches. ;) Uros.
