H1 2015 Priorities and Bare-Metal Programming

[H. S. Teoh via Digitalmars-d]

On Mon, Feb 02, 2015 at 08:55:59AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2/2/15 8:42 AM, Johannes Pfau wrote:
> >Again the problem is not volatileLoad/Store which
> >translate to single instructions it's wrappers.
> 
> So does the argument boil down to better inlining control and
> enforcement?  -- Andrei

FWIW, from the POV of a bystander, the point is that force-inline for
certain things (namely wrappers around certain intrinsics, like operator
overloads for atomics, what-have-you) is necessary in order to guarantee
that function call overhead will not be incurred no matter what.

Walter seems to dislike forced inlining for various reasons, preferring
inlining as a hint at the most, and he probably has a point in most
cases (let the compiler make the judgment). But in other cases, such as
the one in question, the user needs to override the compiler's decision.
Currently there's no way to do that, and it's a showstopper for those
users.

Unless we're proposing to flood the compiler with intrinsics, one for
every possible operator overload of volatile loads/stores, which I think
should be obviously infeasible. And even then, you still might miss one
or two other obscure wrappers that users might discover that they need.
It seems reasonable that instead of burdening the compiler (and compiler
maintainers, and porters) to keep up with an ever-expanding set of
intrinsics, making use of the language to express what is needed via
forced-inline functions is a better way to do things.


T

-- 
If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.