Re: prevent (pre_inc ...) from satisfying "movhi" RTL template constraints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jul 22, 2017 at 01:43:50PM +0100, Maxim Blinov wrote:
> On Sat, Jul 22, 2017 at 2:43 AM, Segher Boessenkool
> <segher@xxxxxxxxxxxxxxxxxxx> wrote:
> > ("i" matches everything "n" does; did you mean "rmi"?  If you did
> > mean "ri", you should use nonmemory_operand).
> 
> The "rni" is not a typo; I was uncertain of the difference between 'n' and 'i',
> so I decided to put both of them in. From the definitions, I deduced that 'i'
> can support symbolic constants and 'n' does not, and I wasn't sure what to
> make of the following definition of 'n':
> 
> > ...Many systems cannot support assembly-time constants for operands
> > less than a word wide. Constraints for these operands should use 'n' rather
> > than 'i'.

(define_constraint "i"
  "Matches a general integer constant."
  (and (match_test "CONSTANT_P (op)")
       (match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)")))

(define_constraint "n"
  "Matches a non-symbolic integer constant."
  (and (match_test "CONST_SCALAR_INT_P (op)")
       (match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)")))

(from common.md).  Any CONST_SCALAR_INT_P is also a CONSTANT_P.

> > > My question is, why does the compiler match the above RTL code to
> > > my "movhi" template? I have not specified an auto {pre,post}
> > > inc/decremented ("<" or ">") operand constraint anywhere in the
> > > "movhi" template; thus, surely the template match should fail, if the
> > > RTL that is attempted to be matched contains such a *cremented
> > > expression?
> >
> > Because your legitimate_address_p (or similar) is fine with it,
> > I suspect.
> 
> The aforementioned RTL is not invalid; legitimate_address_p correctly
> permits addressing of that form. What I would like to do is prevent such
> RTL expressions from matching to the "movhi" template (which in my
> mind, it shouldn't have matched in the first place), so that it only matches
> the "pushhi" template.

memory_operand (via general_operand and memory_addres_addr_space_p)
asks legitimate_address_p.

"m" does as well:

(define_memory_constraint "TARGET_MEM_CONSTRAINT"
  "Matches any valid memory."
  (and (match_code "mem")
       (match_test "memory_address_addr_space_p (GET_MODE (op), XEXP (op, 0),
                                                 MEM_ADDR_SPACE (op))")))

#ifndef TARGET_MEM_CONSTRAINT
#define TARGET_MEM_CONSTRAINT 'm'
#endif

So, you will need different predicates and constraints.  You also have
the problem that the mov<mode> pattern needs to be able to handle most
things thrown at it, so you can't simply disallow the push patterns
here.

Just put the push patterns first?  You are guaranteed if multiple
patterns match, the earliest is chosen, always.


Segher



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux