On Mon, Apr 23, 2012 at 5:14 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote:
>> > 2011-11-17 Andreas Krebbel <andreas.kreb...@de.ibm.com> >> > >> > * reload.c (find_reloads): Change the loop nesting when trying an >> > alternative with swapped operands. >> >> I would just like to point out that constran_operands will have >> problems to re-recognize alternative with swapped commutative >> operands. The "%" operand modifier is ignored there, so i.e. x86 add >> pattern with swapped commutative operands, like: >> >> (set (reg: ax) (plus (reg: bx)(reg: ax))) >> >> will be rejected. > > Well, yes, that's why reload explicitly tries both versions, and > keeps the one that matches ... > > The only thing Andreas' patch changes is the priority in which > different options are tried if there are multiple alternatives. > > For example, if you have a pattern that has commutative operands, > and one of them supports both register and memory, reload can > try: > > 1.) use operands as they are > 2.) spill one operand to memory > 3.) swap operands > 4.) swap operands and spill one operand to memory > > It used to be that reload tried these in order 1, 2, 3, 4; > with Andreas' patch they are now tried in order 1, 3, 2, 4. > (Always assuming there are no priorities like ! or ? specified > in the .md file. Those would override in either case.) > > > Could you explain in more detail the problem you see with that? I don't have any problems with proposed order, but in my failed attempt to convert x86 to post-reload compare elimination, constrain_operands failed to recognize generated combined add+compare pattern, when commutative matched operands were swapped (e.g. the perfectly valid x86 add pattern above). constrain_operands was called from the call to validate_change (please see compare-elim.c) when flags clobber was substituted with compare. Since the order of how commutative operands are handled will be changed, I thought that I should mention this issue with matched commutative operands on the mailing list. Uros.
