On Wed, 20 May 2015, Michael Ferguson wrote:
> On 5/20/15, 9:02 AM, "Jason Riedy" <[email protected]> wrote:
>
>> And Damian McGuckin writes:
>>> On Tue, 19 May 2015, Michael Ferguson wrote:
>>>
>>>> I have verified that GCC at least does not inline frexp. I don't
>>>> understand why it couldn't, but it didn't in my experiments. Neither
>>>> did clang...
>>>
>>> C/C++ does not know the details so cannot expand it. If frexp were
>>> implemented as a template in C++, it is another story, and another
>>> email discussion list.
>>
>> That's frustrating beyond belief, as gcc+glibc has inlined frexp and ldexp
>> for me in the past. The only reason I can see not to inline them is to
>> control trapping behavior, so possibly the change is on the glibc side.
>> grr.
I just had a look at the current frexp/ldexp on BSD, not glibc, and they
look pretty hairy to try and implement in-line. So I can understand why
GCC/G++ might fail. LDEXP has many scenarios to address with underflow,
overflow, subnormals as well as NaNs and Infs, and issues with forcing
writes to memory. FREXP has a few less, but still 4 or 5 cases.
>> (Why sane accessors are missing from 754 is a long story, much of which
>> I try not to remember.)
>
> GCC 4.9.2 appears to have a builtin frexp function. It appears that:
> * using frexp or __builtin_frexp both result in a call to frexp
> * GCC should know enough about both so that they do not inhibit
> optimization, since frexp should be the same as the builtin one.
Is assuming too many things about how optimizers work starting to get into
pretty hairy territory, e.g. GCC/ICC/CLANG/Whatever-else. 4.9.2 is very
recent and more recent than many commercial Linux's might use.
Pulling a IEEE754 apart is not as complicated as what frexp/ldexp try to
achieve. While their functionality has an important place, I am trying
to do simple things here.
Also, in my applications, I would actually figure out, and need to process
appropriately, the various cases that frexp handles (and hides), i.e. an
argument which could be
0.0
strictly negative (sometimes)
subnormal
NaN or Inf (often deliberately avoided long before any call)
anything else
Also, without trying to kill the discussion, aren't we are starting to
digress from Chapel'ness of the discussion. Just my 2c comment.
> Jason, on a related note, what would you consider sane accessors?
Can I second that question? Sounds like something we need to consider if
we are trying to give ourselves a complete IEEE754 environment in Chapel.
Any references?
Humble Suggestion
=================
I haven't thought through this completely but will raise it anyway ...
Take 'frexp'/'ldexp' and 'frexpf'/'ldexpf' and then try and implement
these two directly in Chapel
Looking at that as an exercise may highlight many of the same issues as I
am considering but in vastly a simpler setting.
Thanks - Damian
P.S. Michael,
#include <ieee754.h>
is non-standard. I have been using my own, minimally-hacked variant for so
long, I had forgotten. However, both BSD and Linux have it.
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
