• Cecil Ward (23/23) Jul 27 2020 I read recently that all asm in D is regarded as ‘volatile’ in
• Guillaume Piolat (11/13) Jul 28 2020 Hello,
• Iain Buclaw (23/34) Jul 30 2020 Until recently the absence of the pure keyword implied volatile
• Cecil Ward (7/43) Jul 31 2020 Ah. I wasn’t thinking about pure, although I do use it everywhere
• Iain Buclaw (5/13) Aug 01 2020 When the baseline for asm is volatile, I don't think it's
• Cecil Ward (2/16) Aug 02 2020 We are in agreement.

Cecil Ward <cecil cecilward.com> writes:

I read recently that all asm in D is regarded as ‘volatile’ in 
the GCC sense, which I take to mean that it is assume to 
potentially have side effects, and so cannot be optimised away to 
nothing by the compiler despite the lack of any outputs.

I would like to be able to either use the asm volatile qualifier 
now and have it do absolutely nothing or else have an alternative 
way of expressing the licence for optimisation allowed by the 
designer. If it is now way too late to declare that suddenly the 
_lack_ of volatile means that the compiler can go 
optimisation-crazy, then we need some alternative 
‘is_optimisable’ keyword.

Even if we think that we need an ‘is-optimisable’ qualifier, then 
I would still like to be able to include the asm volatile 
qualifier or similar just to document the designer’s intent in 
cases where we genuinely do have a non-obvious side effect in the 
asm.

What do others think? If others agree, how could a very small DIP 
be set in motion ?

That would mean just adding one or two new keywords for the asm 
qualifier(s), which do precisely nothing at present.

If GCC and LDC were willing to start optimising at some point 
then it would be a matter of doing what the sibling C compilers 
do with volatile and non-volatile.

Guillaume Piolat <first.name gmail.com> writes:

On Tuesday, 28 July 2020 at 06:57:36 UTC, Cecil Ward wrote:
 What do others think? If others agree, how could a very small 
 DIP be set in motion ?

Hello,

LDC lets you do optimizable assembly with ldc.llvmasm.__asm
Better yet, you can also create IR directly with 
ldc.llvmasm.__ir_pure
This will yield results mroe portable and with optimal efficiency 
in a lot of cases.

GDC let's you do optimizable assembly if you can understand its 
arcane syntax!

But all this isn't very useful since doing assembly directly 
rarely lead to fastest results provided you use a modern backend.

Iain Buclaw <ibuclaw gdcproject.org> writes:

On Tuesday, 28 July 2020 at 06:57:36 UTC, Cecil Ward wrote:
 I read recently that all asm in D is regarded as ‘volatile’ in 
 the GCC sense, which I take to mean that it is assume to 
 potentially have side effects, and so cannot be optimised away 
 to nothing by the compiler despite the lack of any outputs.

 I would like to be able to either use the asm volatile 
 qualifier now and have it do absolutely nothing or else have an 
 alternative way of expressing the licence for optimisation 
 allowed by the designer. If it is now way too late to declare 
 that suddenly the _lack_ of volatile means that the compiler 
 can go optimisation-crazy, then we need some alternative 
 ‘is_optimisable’ keyword.

Until recently the absence of the pure keyword implied volatile 
in gdc. I do plan to re-add it, either only in release mode, or 
when warnings are added for the following:

---
asm pure {
   "get flags" : "=r" (x);
}
assert(x == 1);

asm {
   "set flags" : : "r" (x + 1);
}

asm pure {
   "get flags" : "=r" (x);
}
assert(x == 2);
---

The second 'get flags' would be removed if optimizing as it is 
both identical to the first statement, and not clear to the 
compiler that there is a dependency between the setter and getter 
statements.

Just highlighting one example that might be surprising if you 
weren't thinking that optimizing mean that as well.

Cecil Ward <cecil cecilward.com> writes:

On Thursday, 30 July 2020 at 07:05:39 UTC, Iain Buclaw wrote:
 On Tuesday, 28 July 2020 at 06:57:36 UTC, Cecil Ward wrote:
 I read recently that all asm in D is regarded as ‘volatile’ in 
 the GCC sense, which I take to mean that it is assume to 
 potentially have side effects, and so cannot be optimised away 
 to nothing by the compiler despite the lack of any outputs.

 I would like to be able to either use the asm volatile 
 qualifier now and have it do absolutely nothing or else have 
 an alternative way of expressing the licence for optimisation 
 allowed by the designer. If it is now way too late to declare 
 that suddenly the _lack_ of volatile means that the compiler 
 can go optimisation-crazy, then we need some alternative 
 ‘is_optimisable’ keyword.

 Until recently the absence of the pure keyword implied volatile 
 in gdc. I do plan to re-add it, either only in release mode, or 
 when warnings are added for the following:

 ---
 asm pure {
   "get flags" : "=r" (x);
 }
 assert(x == 1);

 asm {
   "set flags" : : "r" (x + 1);
 }

 asm pure {
   "get flags" : "=r" (x);
 }
 assert(x == 2);
 ---

 The second 'get flags' would be removed if optimizing as it is 
 both identical to the first statement, and not clear to the 
 compiler that there is a dependency between the setter and 
 getter statements.

 Just highlighting one example that might be surprising if you 
 weren't thinking that optimizing mean that as well.

Ah. I wasn’t thinking about pure, although I do use it everywhere 
I can as a matter of course. The absence of something doesn’t hit 
you in the eye as an expression of the programmer’s intent I 
suppose, absence of pure just could mean the author forgot to put 
it in. I see your point though. The value of volatile I saw as in 
documentation.

Iain Buclaw <ibuclaw gdcproject.org> writes:

On Saturday, 1 August 2020 at 02:36:41 UTC, Cecil Ward wrote:
 On Thursday, 30 July 2020 at 07:05:39 UTC, Iain Buclaw wrote:
 [...]

 Ah. I wasn’t thinking about pure, although I do use it 
 everywhere I can as a matter of course. The absence of 
 something doesn’t hit you in the eye as an expression of the 
 programmer’s intent I suppose, absence of pure just could mean 
 the author forgot to put it in. I see your point though. The 
 value of volatile I saw as in documentation.

When the baseline for asm is volatile, I don't think it's 
entirely surprising to consider pure as a cancellation of that - 
afterall, if it truly is side-effect free, then it's fine for the 
compiler to remove the statement block.

Cecil Ward <cecil cecilward.com> writes:

On Saturday, 1 August 2020 at 19:23:00 UTC, Iain Buclaw wrote:
 On Saturday, 1 August 2020 at 02:36:41 UTC, Cecil Ward wrote:
 On Thursday, 30 July 2020 at 07:05:39 UTC, Iain Buclaw wrote:
 [...]

 Ah. I wasn’t thinking about pure, although I do use it 
 everywhere I can as a matter of course. The absence of 
 something doesn’t hit you in the eye as an expression of the 
 programmer’s intent I suppose, absence of pure just could mean 
 the author forgot to put it in. I see your point though. The 
 value of volatile I saw as in documentation.

 When the baseline for asm is volatile, I don't think it's 
 entirely surprising to consider pure as a cancellation of that 
 - afterall, if it truly is side-effect free, then it's fine for 
 the compiler to remove the statement block.

We are in agreement.