What exactly is this testing for?  Should I even care if it fails?

https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/test42.d#L613

It *looks* like it is expecting the data to be aligned to 16 bytes. But why should this matter?

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 4/4/2013 9:57 AM, Iain Buclaw wrote:
> What exactly is this testing for?  Should I even care if it fails?
>
> https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/test42.d#L613
>
> It *looks* like it is expecting the data to be aligned to 16 bytes.

Yes.

> But why should this matter?

People use such constructs to support SIMD code, which requires 16 byte alignment.


_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 4 April 2013 19:02, Walter Bright <walter@digitalmars.com> wrote:

>
> On 4/4/2013 9:57 AM, Iain Buclaw wrote:
>
>> What exactly is this testing for?  Should I even care if it fails?
>>
>> https://github.com/D-**Programming-Language/dmd/blob/** master/test/runnable/test42.d#**L613<https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/test42.d#L613>
>>
>> It *looks* like it is expecting the data to be aligned to 16 bytes.
>>
>
> Yes.
>
>
>  But why should this matter?
>>
>
> People use such constructs to support SIMD code, which requires 16 byte alignment.
>
>
Is this expected for all shared types? Or just shared structs.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 4 Apr 2013, at 20:02, Walter Bright wrote:
> On 4/4/2013 9:57 AM, Iain Buclaw wrote:
>> What exactly is this testing for?  Should I even care if it fails?
>>
>> https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/test42.d#L613
>>
>> It *looks* like it is expecting the data to be aligned to 16 bytes.
>
> Yes.
>
>> But why should this matter?
>
> People use such constructs to support SIMD code, which requires 16 byte alignment.

I think you might be wrong here:

»struct A { int[4] a; }« is equivalent to »struct A { int a0, a1, a2, a3; }« by your own definition, and GCC/Clang emit a global of this type aligned to 4 bytes. Thus, generally requiring 16 byte alignment would break C ABI compatibility.

For this reasons, I disabled the test for LDC as well. If you think that it should pass, where does the 16 byte figure come from (in terms of both lang spec and DMD frontend)? At least back when I had a look at the test case for LDC, I couldn't really find a justification.

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 4/5/2013 1:48 AM, Iain Buclaw wrote:
> On 4 April 2013 19:02, Walter Bright <walter@digitalmars.com <mailto:walter@digitalmars.com>> wrote:
>
>
>     On 4/4/2013 9:57 AM, Iain Buclaw wrote:
>
>         What exactly is this testing for?  Should I even care if it fails?
>
>         https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/test42.d#L613
>
>         It *looks* like it is expecting the data to be aligned to 16 bytes.
>
>
>     Yes.
>
>
>         But why should this matter?
>
>
>     People use such constructs to support SIMD code, which requires 16 byte
>     alignment.
>
>
> Is this expected for all shared types? Or just shared structs.
>

It has nothing to do with it being shared or not.

On 4/5/2013 10:15 AM, David Nadlinger wrote:
>
>> People use such constructs to support SIMD code, which requires 16 byte alignment.
>
> I think you might be wrong here:
>
> »struct A { int[4] a; }« is equivalent to »struct A { int a0, a1, a2, a3; }« by your own definition, and GCC/Clang emit a global of this type aligned to 4 bytes. Thus, generally requiring 16 byte alignment would break C ABI compatibility.
>
> For this reasons, I disabled the test for LDC as well. If you think that it should pass, where does the 16 byte figure come from (in terms of both lang spec and DMD frontend)? At least back when I had a look at the test case for LDC, I couldn't really find a justification.
>

I am reluctant to change that, because it would break existing code.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 5 Apr 2013, at 21:16, Walter Bright wrote:
> I am reluctant to change that, because it would break existing code.

Change what? As far as I can see, the test case and any code that relies on that behavior is simply invalid given the "like the host C compiler" clause. Chances are that any such "existing" code doesn't work (reliably) on GDC and LDC today.

If you want different behavior, you *do* have to change the spec.

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 4/5/2013 12:24 PM, David Nadlinger wrote:
> On 5 Apr 2013, at 21:16, Walter Bright wrote:
>> I am reluctant to change that, because it would break existing code.
>
> Change what? As far as I can see, the test case and any code that relies on that behavior is simply invalid given the "like the host C compiler" clause. Chances are that any such "existing" code doesn't work (reliably) on GDC and LDC today.
>
> If you want different behavior, you *do* have to change the spec.

This behavior was a frequent request from those doing SIMD code, which is why it's there, and why I'm reluctant to remove it and break their code.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 5 Apr 2013, at 22:23, Walter Bright wrote:
> On 4/5/2013 12:24 PM, David Nadlinger wrote:
>> On 5 Apr 2013, at 21:16, Walter Bright wrote:
>>> I am reluctant to change that, because it would break existing code.
>>
>> Change what? As far as I can see, the test case and any code that relies on that behavior is simply invalid given the "like the host C compiler" clause. Chances are that any such "existing" code doesn't work (reliably) on GDC and LDC today.
>>
>> If you want different behavior, you *do* have to change the spec.
>
> This behavior was a frequent request from those doing SIMD code, which is why it's there, and why I'm reluctant to remove it and break their code.

Sorry, but I don't think this is a sensible argument at all. We can either
  1) decide that static arrays should be aligned to some special number of bytes, and adapt the spec accordingly, addressing any issues like C ABI compatibility
— or —
  2) remove the (invalid) unit test, and ask any people relying on this undocumented feature to adapt their code.

Doing nothing is certainly not an option.

I'd argue that 2) is the better choice – isn't just using vector types (e.g. core.simd.int4) for storage the best idea in cases where you want to, well, use the data in vector operations?

In related news, I think that telling people that it is okay to rely on undocumented DMD implementation quirks is jeopardizing the future of D in more ways than you might realize, and certainly sends all the wrong signals to people working on alternative implementations.

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 4/5/2013 2:16 PM, David Nadlinger wrote:
> On 5 Apr 2013, at 22:23, Walter Bright wrote:
>> On 4/5/2013 12:24 PM, David Nadlinger wrote:
>>> On 5 Apr 2013, at 21:16, Walter Bright wrote:
>>>> I am reluctant to change that, because it would break existing code.
>>>
>>> Change what? As far as I can see, the test case and any code that relies on that behavior is simply invalid given the "like the host C compiler" clause. Chances are that any such "existing" code doesn't work (reliably) on GDC and LDC today.
>>>
>>> If you want different behavior, you *do* have to change the spec.
>>
>> This behavior was a frequent request from those doing SIMD code, which is why it's there, and why I'm reluctant to remove it and break their code.
>
> Sorry, but I don't think this is a sensible argument at all. We can either
>   1) decide that static arrays should be aligned to some special number of bytes, and adapt the spec accordingly, addressing any issues like C ABI compatibility
> — or —
>   2) remove the (invalid) unit test, and ask any people relying on this undocumented feature to adapt their code.
>
> Doing nothing is certainly not an option.
>
> I'd argue that 2) is the better choice – isn't just using vector types (e.g. core.simd.int4) for storage the best idea in cases where you want to, well, use the data in vector operations?
>
> In related news, I think that telling people that it is okay to rely on undocumented DMD implementation quirks is jeopardizing the future of D in more ways than you might realize, and certainly sends all the wrong signals to people working on alternative implementations.

It's C ABI compatible. Note that:

struct S { int[4] a; }
struct T { int x; S s; }

has a size of 20 bytes. What's going on is when the statically allocated data is emitted, it is aligned to 16 bytes. This does not break the C ABI.

The reason it is marked as "shared" is so it goes into a section in the object file. TLS doesn't always go into a section.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals