[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [PATCH, libstdc++, complex] complex multiplication algorithm improved
From:       Richard Guenther <richard.guenther () gmail ! com>
Date:       2010-09-15 19:54:31
Message-ID: AANLkTi=Q7GZFM6jkNBr3aXVThPDCtNmfCi3uFuxM5XC_ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Sep 15, 2010 at 9:49 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 15 Sep 2010, Richard Guenther wrote:
>
>> On Wed, Sep 15, 2010 at 5:50 PM, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
>> > "Joseph S. Myers" <joseph@codesourcery.com> writes:
>> >
>> > | On Wed, 15 Sep 2010, Richard Guenther wrote:
>> > |
>> > | > easier for the original variant (that is actually something
>> > | > one might consider changing - manually use fma
>> > | > intrinsics when the CPU supports that).
>> > |
>> > | I'd certainly encourage adding support for RTL patterns for __builtin_fma
>> > | (and stopping using RTL for non-fused operations to describe fma
>> > | instructions, doing contracting separately in a way that can be restricted
>> > | when desired to cases where the source language permits it).
>> >
>> > strongly supported.
>>
>> Of course CPUs tend to support a variety of variants with respect to
>> negation of operands ... quite a mess to enumerate them all.
>> Can we somehow provide a container around an rtx that prevents
>> splitting the fma in pieces?
>
> I was imagining RTL such as (neg (fma a b c)) and (fma a b (neg c)) and
> similar - negate is a quiet-computational operation that never raises
> exceptions even for signaling NaN operands and these should be valid ways
> of representing those variants.

Ah, that might work.

Richard.
[prev in list] [next in list] [prev in thread] [next in thread]