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.

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.

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.

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.

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.

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.