nickdesaulniers added a comment.
Linus Torvalds thoughts
<https://lore.kernel.org/linux-pm/CAHk-=wh55h__rc6+rth7plltbnbuuoxpnzggswvdgn7c6nw...@mail.gmail.com/>
on the patches as a result of this change.
> Those uses of 1E6L were perhaps strange, but they were only used in
> constant compile-time expressions that were cast to 'unsigned long' in
> the end, so how the heck did llvm end up with any floating point in
> there?
>
> In this case there was really no excuse not to just use a better
> constant, but there are other situations where it might well be quite
> reasonable to use floating point calculations to create an integer
> constant (eg maybe some spec describes an algorithm in FP, but the
> implementation uses fixed-point arithmetic and has initializers that
> do the conversion).
>
> Imagine for a moment that you want to do fixed-point math (perhaps
> because you have a microcontroller without an FP unit - it's not
> limited to just "the kernel doesn't do FP"). Further imagine just for
> a moment that you still want some fundamental constants like PI in
> that fixed-point format.
>
> The sane way to generate said constants is to do something like
>
> #define FIXPT_1 (1u << FIXPT_SHIFT)
> #define FIXPT_FP(x) ((fixpt_t) (((x)*FIXPT_1)+0.5))
> #define FIXPT_PI FIXPT_FP(3.14159265)
>
> rather than have to do something incredibly stupid and illogical and
> unreadable like
>
> #define FIXPT_PI 205887
>
> So honestly, this seems to be just llvm being completely stupid. The
> fact that you don't want to generate floating point code has *NOTHING*
> to do with floating point literals for constant expressions.
>
> In fact, even if you don't want to generate floating point code -
> again, maybe you don't have a FP unit - doesn't mean that you might
> not want to generate normal floating point constants. You may end up
> having explicit software floating point, and doing things like passing
> the floating point values around manually, ie
>
> union fp {
> uint64_t val;
> double fp_val;
> };
>
> and having code like
>
> static const union fp sqrt2 = { .fp_val = 1.4142.... };
>
> and then doing all the math in 'uint64_t' just because you wrote a
> couple of math routines yourself:
>
> fp_mul(&res, sqrt2.val, x);
>
> again, there's no floating point *code* generated, but that doesn't
> mean that the compiler shouldn't allow users to use floating point
> *values*.
>
> The two
> examples above are very much not about the Linux kernel (although I
> think we actually have a couple of places that do things exactly like
> that) they are about generic coding issues.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D98895/new/
https://reviews.llvm.org/D98895
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
