llvm dev - Jul 2015 - [LLVMdev] [Clang] Reasons for lack of -fsingle-precision-constant support? Alternatives?

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/Floating_Point_Optimization#float_vs._double_vs._long_double
:

*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.

Any thoughts?

Thanks,
Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150715/987728d8/attachment.html>

No real reason, I'm sure, other than a general desire to limit the size of
the zoo of flags that need maintenance.

On Wed, Jul 15, 2015 at 5:01 AM, ed at modk.it <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/Floating_Point_Optimization#float_vs._double_vs._long_double
>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__processors.wiki.ti.com_index.php_Floating-5FPoint-5FOptimization-23float-5Fvs.-5Fdouble-5Fvs.-5Flong-5Fdouble&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=SziAjiSP8N_rg2b1QO6yqe6DPgAQ-gYuJ_OnsXjdwQo&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.
>
> 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/5cfa524f/attachment.html>

Thanks for the response.  If we add the support would you accept the
patch?  Seems like a pretty straightforward flag since it maps directly to
NumericLiteralParser::NumericLiteralParser within LiteralSupport.cpp.  I
understand the maintenance concern with flags that affect multiple points
in code though.

Still trying to get the bottom of why we're crashing with double floating
point literal.  It seems the fpu in question (fpv4-sp-d16) only supports 32
bit operations so this is somehow getting passed to a software wrapper and
crashing there.  But to be fair this was crashing in gcc too which is why
we added the -fsingle-precision-constant flag since we didn't care about
the precision of the constants and we're using floats everywhere anyway for
performance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150715/099d16c2/attachment.html>

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/Floating_Point_Optimization#float_vs._double_vs._long_double
>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__processors.wiki.ti.com_index.php_Floating-5FPoint-5FOptimization-23float-5Fvs.-5Fdouble-5Fvs.-5Flong-5Fdouble&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=SziAjiSP8N_rg2b1QO6yqe6DPgAQ-gYuJ_OnsXjdwQo&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>

>
> 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.
>
>
That would make sense but our tools are so high level we don't even
generate compiler errors because there should be none by design:
http://modkit.com/vex

We can certainly append the 'f' in our highest level tools but we're
working on some tools that are closer to the metal and want to keep things
1:1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150715/96d184a3/attachment.html>