RE: [boost] Re: Re: RE: Math Constants Formal Review - optimisation of unused constants.

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-06-10 16:32:11

| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Ed Brey
| Sent: Tuesday, June 10, 2003 2:30 PM
| To: boost_at_[hidden]
| Subject: [boost] Re: Re: RE: Math Constants Formal Review - recap &
| summary
| 
| 
| Paul A. Bristow wrote:
| >> 
| >> For example, VC 7.1 discards d1 if it is not referenced, so there is
| >> no issue with paying for what you don't use when using that method on
| >> that compiler.
| > 
| > This is good news. What optimisation did you chose?
| 
| /O2
| 
| >>  It would be useful to know what compilers do retain
| >> unused constants.
| > 
| > But is tiresome to find out, and will keep changing.  (and if the
| > scheme becomes widely used, compiler writers will have a strong
| > incentive to make sure it is optimized away.
| 
| Agreed, an active search would be a lot of effort.  I passive 
| approach may be practical however.  My thinking is to start from a 
| position that all compilers optimize well.  Then when someone says, 
| "Sorry, that interface triggers this pessimization on compiler x," 
| just make a note of x and its limitation.  This way to don't need to 
| look for compiler limitations; news of such will come to you.
| 
| There probably aren't a ton of limitations; so the list may well be 
| short, and it can be a big timer saver to know exactly which 
| compilers to care about when they get reved, especially if a removal 
| of a key limitation eliminates the need for a complex workaround.

Sounds sensible.  (I fear the answer to pessimization may be "tough!")

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]   Mobile [phone]
Mobile mailto:pabristow_at_[hidden]
mailto:pbristow_at_[hidden]