On 12/30/2011 10:31 AM, Chad J wrote:
As an aside, I think that people want forced inlining because it gives
them another tool to tweak with. My experiences with optimization tend
to suggest I can usually optimize things really well with a few short
cycles of profile->experiment->profile. I don't think I've ever really
/needed/ to dive into assembly yet. My ventures into the assembler have
been either purely recreational or academic in nature. Now, something
like an inline feature can help a lot with the "experiment" part of the
cycle. It's just another knob to twist and see if it gives the result
you want. Portability be damned, if it gets the thing out the door, I'm
using it! But, I kind of hate that attitude. So it's much more
comforting to be able to twist that knob without sacrificing portability
too. I wouldn't expect it to run as fast on other compilers; I /would/
expect it to compile and run correctly on other compilers. And if
enregistering variables is more important, then we might want to have a
way to enregister variables too.
Back in the olden days, I provided a detailed list of optimizer switches that
turned on/off all sorts of optimizations. In the end it turned out that all
people wanted was an "optimize" switch which is why dmd has only -O.
The reason dmd has a -inline switch is because it's hard to debug code that has
been inlined.
The reason C's "register" keyword went away was because:
1. the variables after optimization transformations may be very different than
before
2. programmers stunk at picking the right variables for registers
3. even if (2) was done right, as soon as the first code maintainer dinked with
it, they never bothered to go fix the register declarations
4. optimizers got pretty good at automatic register allocation
5. there's nothing portable about enregistering, even with a portable syntax
6. the register keyword offered no way to hint which variables were more
important to enregister than others
