www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Which optimisations are are easier or perhaps only possible in the

reply "Stefan Koch" <uplink.coder googlemail.com> writes:
Hello guys,
I want to work on optimisations in the semantic analysis stage.

Could you chime in with thoughts about what can only be there and 
not in llvm-ir for example ?

Thanks Stefan
Dec 10 2014
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 10 December 2014 at 11:07:34 UTC, Stefan Koch wrote:
 Hello guys,
 I want to work on optimisations in the semantic analysis stage.

 Could you chime in with thoughts about what can only be there 
 and not in llvm-ir for example ?

 Thanks Stefan
Well it really depends how descriptive your IR happens to be. Perhaps high-level promises about code that the compiler can't see. E.g. something like commutative float[] convolve(float[] a, float[] b);
Dec 10 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Stefan Koch"  wrote in message news:furihdkmprozoruutsff forum.dlang.org...

 Hello guys,
 I want to work on optimisations in the semantic analysis stage.

 Could you chime in with thoughts about what can only be there and not in 
 llvm-ir for example ?
DMD's inliner might be a good place to start. There is a lot to be done there.
Dec 10 2014
parent reply "Stefan Koch" <uplink.coder googlemail.com> writes:
On Wednesday, 10 December 2014 at 14:02:43 UTC, Daniel Murphy 
wrote:

 DMD's inliner might be a good place to start.  There is a lot 
 to be done there.
I am sure that would be interesting. But I gather PR's for DMD are not merged too frequently.
Dec 10 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 10 December 2014 at 18:39:39 UTC, Stefan Koch wrote:
 On Wednesday, 10 December 2014 at 14:02:43 UTC, Daniel Murphy 
 wrote:

 DMD's inliner might be a good place to start.  There is a lot 
 to be done there.
I am sure that would be interesting. But I gather PR's for DMD are not merged too frequently.
DMD pull requests actually don't languish for too long unless it's a controversial or complicated pull request. DMD gets and merges more pull requests than Phobos.
Dec 10 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Dec 10, 2014 at 10:47:45PM +0000, Brad Anderson via Digitalmars-d wrote:
 On Wednesday, 10 December 2014 at 18:39:39 UTC, Stefan Koch wrote:
On Wednesday, 10 December 2014 at 14:02:43 UTC, Daniel Murphy wrote:

DMD's inliner might be a good place to start.  There is a lot to be
done there.
I am sure that would be interesting. But I gather PR's for DMD are not merged too frequently.
DMD pull requests actually don't languish for too long unless it's a controversial or complicated pull request. DMD gets and merges more pull requests than Phobos.
Yeah, I've submitted relatively simple PRs for dmd, and they usually get merged within a few days, sometimes in a day if it's trivial. T -- Verbing weirds language. -- Calvin (& Hobbes)
Dec 10 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Stefan Koch"  wrote in message news:smlizntnnsppmzsdceln forum.dlang.org...

 I am sure that would be interesting. But I gather PR's for DMD are not 
 merged too frequently.
DMD is where the frontend's development takes place, and the frontend is shared with GDC and LDC. I don't think they maintain significant frontend patches on top of DMD's frontend.
Dec 10 2014
parent reply "Stefan Koch" <uplink.coder googlemail.com> writes:
Could we come back to the topic ?
:)
Dec 10 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Stefan Koch"  wrote in message news:opqczmamanzwcerpawat forum.dlang.org...

 Could we come back to the topic ?
 :)
Why? If the inliner is out because of DMD's merging process, then so is the rest of the frontend.
Dec 11 2014
parent reply "Stefan Koch" <uplink.coder googlemail.com> writes:
On Thursday, 11 December 2014 at 10:59:24 UTC, Daniel Murphy 
wrote:

 Why?  If the inliner is out because of DMD's merging process, 
 then so is the rest of the frontend.
It is not out! But my question was not about dmd specific things, I meant it more generally.
Dec 11 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 11 December 2014 at 21:02, Stefan Koch via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thursday, 11 December 2014 at 10:59:24 UTC, Daniel Murphy wrote:

 Why?  If the inliner is out because of DMD's merging process, then so is
 the rest of the frontend.
It is not out! But my question was not about dmd specific things, I meant it more generally.
I've often thought one of the biggest wins that would seem to affect my code would be comprehensive value range propagation. assert's and contracts can give value range information to the compiler, also comparison statements, bit masks, casts, etc, can truncate the possible value range, which can create many opportunities for optimisations. It would also be really nice to eliminate errors associated with down-casting.
Dec 11 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Manu via Digitalmars-d"  wrote in message 
news:mailman.3072.1418300450.9932.digitalmars-d puremagic.com...

 I've often thought one of the biggest wins that would seem to affect
 my code would be comprehensive value range propagation.
 assert's and contracts can give value range information to the
 compiler, also comparison statements, bit masks, casts, etc, can
 truncate the possible value range, which can create many opportunities
 for optimisations. It would also be really nice to eliminate errors
 associated with down-casting.
I'd be very interested to see the frontend using (more) information from asserts/preconditions to optimize code. There's a huge amount of potential there.
Dec 11 2014
prev sibling parent "Stefan Koch" <uplink.coder googlemail.com> writes:
On Thursday, 11 December 2014 at 12:20:50 UTC, Manu via 
Digitalmars-d wrote:
 I've often thought one of the biggest wins that would seem to 
 affect
 my code would be comprehensive value range propagation.
 assert's and contracts can give value range information to the
 compiler, also comparison statements, bit masks, casts, etc, can
 truncate the possible value range, which can create many 
 opportunities
 for optimisations. It would also be really nice to eliminate 
 errors
 associated with down-casting.
Great suggestion Manu. We are on the same page here! I will see what I can do about data-flow-analysis in the frontend. This has been requested before. Time to do something about it :) Just don't expect results too quickly, qcc (and looking for a job) takes much of my time.
Dec 11 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 11 December 2014 at 11:02:31 UTC, Stefan Koch wrote:
 On Thursday, 11 December 2014 at 10:59:24 UTC, Daniel Murphy 
 wrote:

 Why?  If the inliner is out because of DMD's merging process, 
 then so is the rest of the frontend.
It is not out! But my question was not about dmd specific things, I meant it more generally.
More generally, you don't want to optimize anything in the frontend: - It is gonna create unscrutable code for debug. - You optimize before inlining, and so won't get the optimization allowed by inlining. You want to add metadata to your IR int he front end to inform the middle and back end. You proceed to : - optimize callee - estimate cost of inlining optimized callee and possibly inline - optimize caller Note that this is a recursive process. You may do a second dance in the backend to get all platform specific optimization going on.
Dec 11 2014
parent "Stefan Koch" <uplink.coder googlemail.com> writes:
On Friday, 12 December 2014 at 00:20:30 UTC, deadalnix wrote:
 More generally, you don't want to optimize anything in the 
 frontend:
  - It is gonna create unscrutable code for debug.
  - You optimize before inlining, and so won't get the 
 optimization allowed by inlining.

 You want to add metadata to your IR int he front end to inform 
 the middle and back end. You proceed to :
  - optimize callee
  - estimate cost of inlining optimized callee and possibly 
 inline
  - optimize caller

 Note that this is a recursive process. You may do a second 
 dance in the backend to get all platform specific optimization 
 going on.
Thanks deadalnix. I thought about using meta-data. I guess this is the most sensible road.
Dec 11 2014