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: MD representation of IA64 floating point operations


Jim Wilson <wilson@specifixinc.com> writes:

> On Thu, 2004-07-22 at 15:06, Zack Weinberg wrote:
>>   (set (match_operand:RF 0 "fr_register_operand" "=f")
>>        (float_extend:RF
>>          (float_truncate:SF
>>            (plus:RF (match_operand:RF 1 "fr_register_operand" "%f")
>>                     (match_operand:RF 2 "fr_reg_or_fp01_operand" "fG")))))
...
> But I think that is a moot point, as I think this change is unnecessary
> and a bad idea.  I think you are confusing datatype with representation
> here.  All gcc cares about is the datatype.  The representation is
> irrelevant.  So the correct way to emit RTL for an SFmode operation is
> exactly what is in the md file already.

In that case, how do you suggest I write the patterns that the
div/sqrt splitters and the generic RFmode support will need?  I
initially considered

  (set (match_operand:RF 0 "fp_register_operand" "=f")
       (add:RF (float_extend:RF (match_operand:SF 1 "fp_register_operand" "f"))
               (float_extend:RF (match_operand:SF 2 "fp_register_operand" "f"))
  ))

but this requires separate patterns for every possible combination of
operand modes - 64 patterns for a three-operand instruction like this
one, 256 patterns for a four-operand instruction like fma.  Times two
for altsf forms.  Times two for define_cond_exec.  All of these forms
are potentially accessible to the user via __fpreg, so we can't limit
it to the ones that are needed internally.

zw


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