Opened 5 years ago

Last modified 4 years ago

#9276 new task

audit ghc floating point support for IEEE (non)compliance

Reported by: carter Owned by: carter
Priority: normal Milestone:
Component: Compiler Version: 7.8.2
Keywords: Cc: jrp
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking: #3070, #8364, #9530
Related Tickets: #9304 Differential Rev(s):
Wiki Page:

Description

As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation.

This impacts both a number of other tasks i wish to do for ghc and much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to:

a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point.

(this may grow into a few subtickets, we'll see)

Change History (16)

comment:1 Changed 5 years ago by schyler

The constant folder doesn't actually fold floating points yet.

It's a hard thing to do, without blowing up cross compilation.

Version 0, edited 5 years ago by schyler (next)

comment:2 Changed 5 years ago by augustss

You can check if the host and the target have the same kind of FP (easy if host==target) and only constant fold under that condition.

comment:3 Changed 5 years ago by carter

yeah, i'm not concerned with even doing optimization yet, just making sure all the suitable primitives are exposed :)

comment:4 Changed 5 years ago by schyler

Blocking: 9304 added

comment:5 Changed 5 years ago by schyler

@augustss: Ideally, adapters should be used to emulate floating point behaviour. I'm not sure how complex it is, but you shouldn't lose any optimisations in cross compiling -- what if cross compiling is normal, i.e. embedded?

Last edited 5 years ago by schyler (previous) (diff)

comment:6 Changed 5 years ago by carter

Yeah, improving optimization requires a pretty precise soft float model of the target hardware's floating point semantics, with roughly three modes

  1. IEEE / machine model -- same result as if run as a normal program
  2. fast math model -- assume associativity, assume NaNs never happen
  3. excess precision -- use extra precision in the intermediate computation to provide as many bits of precision as possible

adding that sort of machinery to ghc is a bit out of scope for just an audit (and any induced patched to provide added missing operations), but becomes possible once such an audit is done. (Also a LOT of work)

I want to get this done for 7.10, adding optimization on top can be on the table later though! :)

comment:7 Changed 5 years ago by carter

though if someone writes that soft model tooling for at least case (1), maybe it could happen faster! :)

comment:8 Changed 5 years ago by carter

Blocking: 8364 added

comment:9 Changed 5 years ago by jrp

Cc: jrp added

comment:10 Changed 5 years ago by carter

Blocking: 9530 added

comment:11 Changed 5 years ago by carter

Blocking: 3070 added

comment:12 Changed 5 years ago by carter

Milestone: 7.10.17.12.1
Priority: highnormal

remilestoning to 7.12,

comment:13 Changed 4 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:14 Changed 4 years ago by thomie

Blocking: 9304 removed

comment:15 Changed 4 years ago by thomie

See also #9304.

comment:16 Changed 4 years ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.