digitalmars.D.bugs - [Issue 936] New: Optimization by compiler hints
- d-bugmail puremagic.com (18/18) Feb 06 2007 http://d.puremagic.com/issues/show_bug.cgi?id=936
- d-bugmail puremagic.com (7/7) Feb 07 2007 http://d.puremagic.com/issues/show_bug.cgi?id=936
- d-bugmail puremagic.com (7/7) Feb 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=936
- d-bugmail puremagic.com (7/7) Feb 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=936
- d-bugmail puremagic.com (10/10) Feb 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=936
- d-bugmail puremagic.com (8/8) Feb 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=936
- d-bugmail puremagic.com (15/18) Feb 10 2007 http://d.puremagic.com/issues/show_bug.cgi?id=936
- d-bugmail puremagic.com (12/12) Feb 10 2007 http://d.puremagic.com/issues/show_bug.cgi?id=936
http://d.puremagic.com/issues/show_bug.cgi?id=936 Summary: Optimization by compiler hints Product: D Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: arkangath gmail.com The Microsoft C++ compiler used compiler hints such as assume(var<[constant]); to help the compiler optimize code. DMD could also benefit from similar hints to improve optimizations. Actually, rather than removing "assert"s from debug code, why not use it's conditions to optimize code in release version? --
Feb 06 2007
http://d.puremagic.com/issues/show_bug.cgi?id=936 If such things are added I would hope they are added as pragmas rather than language keywords, becuase these sorts of hints have a way of becoming useless and even counterproductive as compilers get smarter. C.f. the C 'register' keyword. --
Feb 07 2007
http://d.puremagic.com/issues/show_bug.cgi?id=936 arkangath gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |677 Status|NEW |ASSIGNED --
Feb 09 2007
http://d.puremagic.com/issues/show_bug.cgi?id=936 arkangath gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn|677 | Status|ASSIGNED |NEW --
Feb 09 2007
http://d.puremagic.com/issues/show_bug.cgi?id=936 smjg iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smjg iname.com The reporter's point is that one of these ways in which compilers can become smarter is by using assert expressions as optimisation hints. Why add a pragma as an extra way of doing the same thing? --
Feb 09 2007
http://d.puremagic.com/issues/show_bug.cgi?id=936 I've never heard of "assume" and don't know what it does, so I thought he was suggesting to add a new "assume" keyword and other "compiler hints such as" that to D. Taking hints from existing expressions like assert() would be fine by me. Taking hints from contracts would also be cool. --
Feb 09 2007
http://d.puremagic.com/issues/show_bug.cgi?id=936The reporter's point is that one of these ways in which compilers can become smarter is by using assert expressions as optimisation hints. Why add a pragma as an extra way of doing the same thing?An assert indicates "this is true". A pragma could add a way to say "this is *probably* true". The compiler could then perhaps emit code optimized to run the most likely path as fast as possible, at the expense of less likely paths. For instance, you could tell it that it's unlikely a function returned an error code (let's assume this was a C function that doesn't know about exceptions) so perhaps the code for when the error occurs should be the one performing a jump instruction[1]. [1]: I read somewhere that conditional jumps are less expensive when the condition does not hold. I have no idea if this is still the case for modern processors, this is just an example. --
Feb 10 2007
http://d.puremagic.com/issues/show_bug.cgi?id=936 When debugging code,conditions in asserts are expected to be *always* true, and not probably. If we intent to have probable conditions, the release code would have some sort of handling of such situations. Pragmas for probabilities are not so useful. Consider that in a switch a case is more probable than other, the programmer would just change the order of cases, and not adding a pragma to do the same thing which would just bloat the code. As an example, in a getCurrentDay() function, we expect the return value never to be bigger than 31, and out{} contract would be perfect to (possibly) optimize the code. It is a certainty, not a probability. --
Feb 10 2007