This is the mail archive of the gcc-patches@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: Inline sqrt for ia64


Richard Henderson <rth@redhat.com> writes:

> On Sun, Oct 26, 2003 at 11:30:18AM -0800, Zack Weinberg wrote:
>> And wouldn't you then have to define arithmetic operations on this
>> rather peculiar mode?
>
> No.  It would not be a user accessible type.  The only valid
> operation on it would be extend.

I worry about other parts of the compiler trying to do clever things
with it (having just been through that ad nauseam myself).  Besides
which, it feels like this really ought to be a named RTL operation.
It's ldexp(1.0, value); if we had LDEXP rtl, then we could write

(define_expand "ldexpxf"
  [(set (match_dup 3)
        (ldexp:XF (const_int 1)
                  (match_operand:SI 2 "gr_register_operand" "r")))
   (set (match_operand:XF 0 "fr_register_operand" "f")
        (mul:XF (match_operand:XF 1 "fr_register_operand" "f")
                (match_dup 3)))]
   "check range on operand 2 here somehow"
{
  operands[3] = gen_reg_rtx (XFmode);
})

(define_insn "*ldexpxf_one"
  [(set (match_operand:XF 0)
        (ldexp:XF (const_int 1)
                  (match_operand:SI 1 "gr_register_operand" "r")))]
  ""
  "setf.exp %0 = %1"
  [...])

and teach the constant pool logic to use ldexp?f when it'll help.

I don't know how to represent setf.sig; it can be used to optimize
general MUL operations when one operand is a power of two, but how do
we know that?  And I don't know if the above ought to be a
define_insn_and_split.

zw


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