On Tue, 13 Mar 2018, NightStrike wrote:

Well, if it'd be inline functions in a header, I'd be inclined to agree.
All of these are in non-inline functions (e.g. like the sqrt function,
where you expect it to always produce one "fsqrt" instruction), so I
don't expect any losses there.

Is that always the case? I'm pretty sure that if they compiler can deduce
any optimization, it'll take it. For instance, if it knows you want the
square root of 4, it'll remove the instruction entirely and just use the
number 2.

Well, consider this:

static inline double foo(double x) {
    double out;
    asm(/* math procedure */ :"=t"(out) :"0"(x));
    return out;

void func(double x) {
    double y = foo(x);
    double z = foo(x);

If the asm is nonvolatile, I think the compiler could conclude that z and y will be identical and only expand the asm once.

However, if the asm is volatile, it also means that the asm could have other side effects and can't be moved or omitted, but forcing the compiler to always emit it exactly where it's invoked.

Or that's at least my understanding of the matter.

Therefore, for cases when we have an implementation of a function in a standalone translation unit, volatile shouldn't really matter. But for public functions in headers, functions that can be inlined, volatile makes it potentially less efficient, inhibiting some optimizations. But our headers currently have all the corresponding inline asm in math.h marked as volatile. Theoretically, if everything is right (and if bugs like the clang bug I ran into were fixed), I think it should be fine to remove. But who knows how many other subtle issues it could cause or other lingering bugs it could expose.

// Martin

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Mingw-w64-public mailing list

Reply via email to