From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,6b8760de26d569f1
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!.POSTED!not-for-mail
From: =?ISO-8859-15?Q?Markus_Sch=F6pflin?= <no.spam@spam.spam>
Newsgroups: comp.lang.ada
Subject: Re: gnat 4.4.5 generates surprising code when enabling FP checks
Date: Fri, 08 Apr 2011 12:43:32 +0200
Organization: Aioe.org NNTP Server
Message-ID: <inmosj$7dv$1@speranza.aioe.org>
References: <inkmbf$lhb$1@speranza.aioe.org>
 <4d9df01c$0$7669$9b4e6d93@newsspool1.arcor-online.net>
NNTP-Posting-Host: MdpKeRr+sx3LK7JQiK5aNw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
X-Notice: Filtered by postfilter v. 0.8.2
Xref: g2news2.google.com comp.lang.ada:19687
Date: 2011-04-08T12:43:32+02:00
List-Id: <comp.lang.ada>

Am 07.04.2011 19:10, schrieb Georg Bauhaus:

> Since much of the generated code is a consequence of -gnatVA
> (which implies -gnatVf), shouldn't a smaller selection validity
> checking do the trick, i.e. if you exclude -gnatVf?

The point was to have floating point validity checks on, so using -gnatVaF 
unfortunately is not an option.

The project in question used gcc 3.4 and was migrated to a newer gnat 
version, resulting in a serious performance degradation which I'm currently 
investigating.

I think I found the option which is responsible for the degradation (it's 
-gnatVc which is implied by -gnatVa and whose behaviour seems to have 
changed significantly for gcc 4.x).

The thing that surprised me was that the multiplication is actually 
performed twice, I was kind of expecting it to be only done once.

Currently I'm thinking of taking a step backwards and check what the 
project really needs in terms of validity checks in order to catch invalid 
floats (INFs and NAN) as soon as possible.

It looks like using 'type FLOAT_T is new FLOAT range FLOAT'Range' instead 
of unchecked IEEE floats with -gnatVa generates significantly better 
assembler code, so we might be able to just use -gnatVfpr instead.

Regards,
Markus