www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Help with a DMD patch

reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
I'm trying to cut my teeth on DMD hacking with a simple 
optimization ( http://d.puremagic.com/issues/show_bug.cgi?id=9477 
), but not having much luck so far - the backend is rejecting my 
attempts with asserts here or there. Since the asserts have no 
error messages, and the code is very terse, often 
un-straightforward and lacking in comments, I have no idea if I'm 
feeding it bad input or if it's some latent bug.

Here's my work so far:
https://github.com/CyberShadow/dmd/compare/fix9477-work

Could a DMD guru have a look and tell me what I'm doing wrong?

Tests:
https://gist.github.com/CyberShadow/5177509
Mar 16 2013
next sibling parent "Igor Stepanov" <wazar.leollone yahoo.com> writes:
What do the lines el_combine? I do not see them in the code 
structure comparison.
Mar 16 2013
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 16 March 2013 at 21:15:32 UTC, Igor Stepanov wrote:
 What do the lines el_combine? I do not see them in the code 
 structure comparison.

Greetings Igor, The el_combine calls are supposed to ensure correct order of evaluation. I based that code from this fragment: https://github.com/D-Programming-Language/dmd/blob/635c6b07/src/e2ir.c#L2702
Mar 16 2013
prev sibling next sibling parent "Igor Stepanov" <wazar.leollone yahoo.com> writes:
On Saturday, 16 March 2013 at 21:21:51 UTC, Vladimir Panteleev 
wrote:
 On Saturday, 16 March 2013 at 21:15:32 UTC, Igor Stepanov wrote:
 What do the lines el_combine? I do not see them in the code 
 structure comparison.

Greetings Igor, The el_combine calls are supposed to ensure correct order of evaluation. I based that code from this fragment: https://github.com/D-Programming-Language/dmd/blob/635c6b07/src/e2ir.c#L2702

Visually, it should work :) I would try to make sure that the various components of expression are correctly calculated. In particular, I am concerned the calculation of the length of a dynamic array. You can try to do so, that would return the length of the entire expression. / ***** In DMD ***** / if (t1->ty == Tarray) { retrun el_una(I64 ? OP128_64 : OP64_32, TYsize_t, el_same(&earr1)); } / ***** In D ***** / int[] arr = [1,2,3]; int[] arr3 = [1,2,3,4,5]; size_t len = cast(size_t)(arr == arr3); assert(len == arr.length);
Mar 16 2013
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 16 March 2013 at 21:42:31 UTC, Igor Stepanov wrote:
 On Saturday, 16 March 2013 at 21:21:51 UTC, Vladimir Panteleev 
 wrote:
 On Saturday, 16 March 2013 at 21:15:32 UTC, Igor Stepanov 
 wrote:
 What do the lines el_combine? I do not see them in the code 
 structure comparison.

Greetings Igor, The el_combine calls are supposed to ensure correct order of evaluation. I based that code from this fragment: https://github.com/D-Programming-Language/dmd/blob/635c6b07/src/e2ir.c#L2702

Visually, it should work :) I would try to make sure that the various components of expression are correctly calculated. In particular, I am concerned the calculation of the length of a dynamic array. You can try to do so, that would return the length of the entire expression. / ***** In DMD ***** / if (t1->ty == Tarray) { retrun el_una(I64 ? OP128_64 : OP64_32, TYsize_t, el_same(&earr1)); } / ***** In D ***** / int[] arr = [1,2,3]; int[] arr3 = [1,2,3,4,5]; size_t len = cast(size_t)(arr == arr3); assert(len == arr.length);

Dynamic arrays work perfectly, it's the static ones I'm having trouble with... particularly, when they're being returned from a function. From what I can tell, the situation is that I can neither copy them using el_same (it neither makes sense, as the arrays can be large, nor does the compiler let me to), nor can I take their address, because the code generator fails to process an OPaddr elem when its child is a function call. However, the same thing seems to work when calling the runtime function for array equality (the current implementation)...
Mar 16 2013
prev sibling next sibling parent "Igor Stepanov" <wazar.leollone yahoo.com> writes:
On Saturday, 16 March 2013 at 21:49:33 UTC, Vladimir Panteleev 
wrote:
 On Saturday, 16 March 2013 at 21:42:31 UTC, Igor Stepanov wrote:
 On Saturday, 16 March 2013 at 21:21:51 UTC, Vladimir Panteleev 
 wrote:
 On Saturday, 16 March 2013 at 21:15:32 UTC, Igor Stepanov 
 wrote:
 What do the lines el_combine? I do not see them in the code 
 structure comparison.

Greetings Igor, The el_combine calls are supposed to ensure correct order of evaluation. I based that code from this fragment: https://github.com/D-Programming-Language/dmd/blob/635c6b07/src/e2ir.c#L2702

Visually, it should work :) I would try to make sure that the various components of expression are correctly calculated. In particular, I am concerned the calculation of the length of a dynamic array. You can try to do so, that would return the length of the entire expression. / ***** In DMD ***** / if (t1->ty == Tarray) { retrun el_una(I64 ? OP128_64 : OP64_32, TYsize_t, el_same(&earr1)); } / ***** In D ***** / int[] arr = [1,2,3]; int[] arr3 = [1,2,3,4,5]; size_t len = cast(size_t)(arr == arr3); assert(len == arr.length);

Dynamic arrays work perfectly, it's the static ones I'm having trouble with... particularly, when they're being returned from a function. From what I can tell, the situation is that I can neither copy them using el_same (it neither makes sense, as the arrays can be large, nor does the compiler let me to), nor can I take their address, because the code generator fails to process an OPaddr elem when its child is a function call. However, the same thing seems to work when calling the runtime function for array equality (the current implementation)...

Probably a stupid question, but why do you want to use el_same? As I understand it, el_same creates a copy. Why not use the original, if we know that it will not change anything.
Mar 16 2013
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 16 March 2013 at 22:14:22 UTC, Igor Stepanov wrote:
 Probably a stupid question, but why do you want to use el_same? 
 As I understand it, el_same creates a copy. Why not use the 
 original, if we know that it will not change anything.

As I understand, one "elem" can appear only once in the backend tree. When I tried otherwise, I got asserts in the optimizer, and I've never seen code that reuses elem nodes.
Mar 16 2013
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:pzqxkiigdvvicqkqahpn forum.dlang.org...
 I'm trying to cut my teeth on DMD hacking with a simple optimization ( 
 http://d.puremagic.com/issues/show_bug.cgi?id=9477 ), but not having much 
 luck so far - the backend is rejecting my attempts with asserts here or 
 there. Since the asserts have no error messages, and the code is very 
 terse, often un-straightforward and lacking in comments, I have no idea if 
 I'm feeding it bad input or if it's some latent bug.

 Here's my work so far:
 https://github.com/CyberShadow/dmd/compare/fix9477-work

 Could a DMD guru have a look and tell me what I'm doing wrong?

 Tests:
 https://gist.github.com/CyberShadow/5177509

Instead of copying elems, try to generate something like this: (auto tmp1 = e1, auto tmp2 = e2, tmp1.length == tmp2.length && !memcmp(tmp1.ptr, tmp2.ptr)) There is code in e2ir that already does stuff like this. Not really the easiest part of dmd to hack on....
Mar 16 2013
parent reply Martin Nowak <code dawg.eu> writes:
On 03/17/2013 03:35 AM, Daniel Murphy wrote:
 Not really the easiest part of dmd to hack on....

Yeah, that's why I wished more of this would move to druntime, but the current solution to stuff everything into object.di doesn't scale too well. Looking at "a[] = b[]" => memcpy might help. https://github.com/D-Programming-Language/dmd/blob/6b634f369a53cdc297d0f41c50d03f8b091ea074/src/e2ir.c#L2824
Mar 18 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-18 22:10, Martin Nowak wrote:

 Yeah, that's why I wished more of this would move to druntime, but the
 current solution to stuff everything into object.di doesn't scale too well.

Put it in some other file and add a public import to object.di. -- /Jacob Carlborg
Mar 19 2013
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sunday, 17 March 2013 at 02:35:30 UTC, Daniel Murphy wrote:
 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in 
 message
 news:pzqxkiigdvvicqkqahpn forum.dlang.org...
 I'm trying to cut my teeth on DMD hacking with a simple 
 optimization ( 
 http://d.puremagic.com/issues/show_bug.cgi?id=9477 ), but not 
 having much luck so far - the backend is rejecting my attempts 
 with asserts here or there. Since the asserts have no error 
 messages, and the code is very terse, often un-straightforward 
 and lacking in comments, I have no idea if I'm feeding it bad 
 input or if it's some latent bug.

 Here's my work so far:
 https://github.com/CyberShadow/dmd/compare/fix9477-work

 Could a DMD guru have a look and tell me what I'm doing wrong?

 Tests:
 https://gist.github.com/CyberShadow/5177509

Instead of copying elems, try to generate something like this: (auto tmp1 = e1, auto tmp2 = e2, tmp1.length == tmp2.length && !memcmp(tmp1.ptr, tmp2.ptr))

That's pretty much what my first attempt was. It asserts when I try to save a temporary copy of a static array. Also, it is undesirable if the array happens to be large...
Mar 17 2013
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 16 March 2013 at 18:15:06 UTC, Vladimir Panteleev 
wrote:
 Could a DMD guru have a look and tell me what I'm doing wrong?

Gaaah! My test program doesn't compile even without my patches! I was fighting against pre-existing bugs in DMD... Even more embarrassing, is that I had found and filed this bug myself: http://d.puremagic.com/issues/show_bug.cgi?id=9402
Mar 18 2013
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
https://github.com/D-Programming-Language/dmd/pull/1766
Mar 18 2013
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 18 March 2013 at 21:10:15 UTC, Martin Nowak wrote:
 On 03/17/2013 03:35 AM, Daniel Murphy wrote:
 Not really the easiest part of dmd to hack on....

Yeah, that's why I wished more of this would move to druntime, but the current solution to stuff everything into object.di doesn't scale too well. Looking at "a[] = b[]" => memcpy might help. https://github.com/D-Programming-Language/dmd/blob/6b634f369a53cdc297d0f41c50d03f8b091ea074/src/e2ir.c#L2824

Thanks, I've already tracked it down to a pre-existing DMD bug. Many of my previous attempts were actually correct. I submitted the pull request just now.
Mar 18 2013