Am Sun, 27 Sep 2015 16:48:21 +0200 schrieb Artur Skawina via Digitalmars-d <[email protected]>:
> On 09/27/15 13:48, Marco Leise via Digitalmars-d wrote: > > Am Sat, 26 Sep 2015 19:58:14 +0200 > > schrieb Artur Skawina via Digitalmars-d > > <[email protected]>: > > > >> `allow` is the default state and always safe; for the cases > >> where it's /undesirable/, there is noinline. > > > > No what I meant was when the compiler sees inline assembly or > > anything else it deems not safe to inline, you can convice it > > anyways. It is more like @trusted on otherwise @system > > functions. I just mentioned it so it is under consideration, > > as I have seen it in LLVM. > > The problem with this would be that it would soon lead to a > C-like mess -- a lot of function marked with `allow` just-in-case. > Failure to inline is a compiler implementation problem, it > shouldn't affect the language, which already has enough > annotation noise. > What would be the cases for `allow`, that are /not/ caused > by compiler limitations? (dmd's legacy inline asm hack is not > part of the language in practice, so that does not count) I have no idea, ask the LLVM team for more information. At least as I understood it would be a rare need. A stupid example would be alloca(). Functions that contain it are not inlined and that is not a compiler limitation. Now you might manipulate the stack pointer in asm and the compiler could stop inlining although you know it is safe. Something like that maybe. > Also keep in mind that `noinline` will often not come alone, > but be accompanied by other annotations like `noclone`. > `noinline` often means that the functions identity matters, > so you have to disable cross-function constant propagation > etc too. It can all be done by bundling the attributes via > alias, but the defaults must be sane, so that most code > does not need annotations (for example: a templated function > containing a mixin must not require @inlinable @clonable @etc > just because the mixed in code, that is not locally known, > /might/ silently turn off inlining). > > artur In general I don't see inlining attributes much used at all because of the sane defaults we already have and the aggressive inlining performed by modern compilers. For me the option to build a release version and mark a single function "noinline" is interesting to see it as a separate item in a profiler or to set a breakpoint on it in a debugger and see all the assembly as one block. But first we need to agree on names in core.attribute. I find the GCC names pretty good. "force" is stronger than "always". Unless, to support DMD, we want a more fuzzy thing that doesn't really enforce anything unless -inline is active. -- Marco
