[LLVMdev] [Clang] Reasons for lack of -fsingle-precision-constant support? Alternatives? (original) (raw)

Philip Reames listmail at philipreames.com
Wed Jul 15 09:30:14 PDT 2015

On 07/15/2015 05:01 AM, ed at modk.it wrote:

Hi All,

Clang lacks support for the -fsingle-precision-constant flag. Are there specific reasons for this or is it just waiting to be implemented? This flag is especially important in the embedded world. From http://processors.wiki.ti.com/index.php/FloatingPointOptimization#floatvs.doublevs.longdouble <https://urldefense.proofpoint.com/v2/url?u=http-3A_processors.wiki.ti.comindex.phpFloating-5FPoint-5FOptimization-23float-5Fvs.-5Fdouble-5Fvs.-5Flong-5Fdouble&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4bhmuhMHA&m=SziAjiSP8Nrg2b1QO6yqe6DPgAQ-gYuJOnsXjdwQo&s=q4wtrH7nx201oaODowm17ir7UAGlp2RfLweJDCQuXLA&e=>: /Once all of your data is defined as float, there are still cases where you may unknowingly cause the compiler to generate double precision operations. The most common issue is when floating point literals such as 3.14159 are used. In C these literals are of type double, and if they are used in an expression consisting of single precision operands, the operations will be promoted to double precision. The proper way to specify a single precision literal is to use an 'f' suffix, 3.14159f./ / / While defining literals without the 'f' suffix may point to performance issues, in our case the target crashes when the 'f' is omitted. This is an end user programmable system where we can't expect users to add the 'f'. I don't fully understand why this occurs (this is a bare metal system where user code is run by a quasi-OS which is maintained by a different team and itself is compiled with a different compiler so it's hard to track down) we remedied this with the -fsingle-precision-constant in gcc. Now that we're moving to clang/llvm we need a solution and expecting the user to add 'f' is not going to work. Another approach might be to add a dedicated warning (off by default) which warns or errors on these cases. It also seems like a case where a clang-tidy rewrite rule could help. Any thoughts? Thanks, Ed

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150715/41ae2163/attachment.html>

More information about the llvm-dev mailing list