This is the mail archive of the gcc@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: i370 port


Paul Edwards wrote:

> > As an alternative to the operand predicate, you might also add
> > an extra check to the insn condition.  For example, something
> > along the following lines should work:
> > 
> > (define_insn ""
> >   [(set (match_operand:SI 0 "register_operand" "=d")
> >         (mult:SI (match_operand:SI 1 "register_operand" "0")
> >                  (match_operand:SI 2 "const_int_operand" "K")))]
> >   "CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"
> 
> My eyes lit up when I saw that!  However, it produced a compiler
> error when I tried it.  But undeterred, I tried this:
> 
> (define_insn ""
>   [(set (match_operand:SI 0 "register_operand" "=d")
>         (mult:SI (match_operand:SI 1 "register_operand" "0")
>                  (match_operand:SI 2 "immediate_operand" "K")))]
>   "(GET_CODE (operands[2]) == CONST_INT
>    && REG_P (operands[0])
>    && CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))"

Huh.  Instead of adding an explicit CONST_INT check, my approach
above used a const_int_operand predicate (instead of immediate_operand).
That should have had the exact same effect ...   I'm not sure why the
REG_P check on the other operand would be necessary at this point.

> And it worked (verified by self-compile)!  And I relaxed the 
> constraint on the "M" instruction as well.  Those old warnings 
> are apparently irrelevant now.  Thank you sir.  :-)

OK, that's good to know.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


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