This is an archive of the discontinued LLVM Phabricator instance.

Add getSizeInBits function to the APFloat class
ClosedPublic

Authored by tberghammer on Mar 18 2015, 6:51 AM.

Details

Summary

Add getSizeInBits function to the APFloat class

The newly added function returns the size of the specified floating point semantics in bits.

Diff Detail

Event Timeline

tberghammer retitled this revision from to Add getSizeInBits function to the APFloat class.
tberghammer updated this object.
tberghammer edited the test plan for this revision. (Show Details)
tberghammer added a reviewer: chandlerc.
tberghammer added a subscriber: Unknown Object (MLST).

The function will be first used from LLDB

This is wrong for x87 long doubles (implicit '1' always present, so the count is off by one) and PPC double doubles (weird 128 bit format). It's probably best to just hardcode the value for all supported fp formats.

Use hard coded size values

hfinkel added inline comments.
lib/Support/APFloat.cpp
3374

Why not just add this number to the fltSemantics structure itself?

tberghammer added inline comments.Mar 18 2015, 8:26 AM
lib/Support/APFloat.cpp
3374

I think it is not really part of the semantic, but I can move it to there if you want.
If I move it into the semantic then what should be the size value of calcSemantic in roundSignificandWithExponent? It isn't used by anybody (yet) but we still should give it a reasonable value.

chandlerc requested changes to this revision.Apr 14 2015, 7:44 AM
chandlerc edited edge metadata.

I think I agree with Hal and this should be in the semantic struct. Open to other suggestions though.

This revision now requires changes to proceed.Apr 14 2015, 7:44 AM
tberghammer edited edge metadata.

Move size into the semantics

Friendly ping

Friendly ping

hfinkel accepted this revision.Jul 8 2015, 6:55 PM
hfinkel edited edge metadata.

LGTM.

lib/Support/APFloat.cpp
3372

This { should be on the previous line.

3374

If I move it into the semantic then what should be the size value of calcSemantic in roundSignificandWithExponent? It isn't used by anybody (yet) but we still should give it a reasonable value.

I'd just leave it as 0 as you now have it. It also has 0 precision ;)

This revision was automatically updated to reflect the committed changes.