Jump to page: 1 2
Thread overview
[Issue 15110] pragma(inline) rarely works how I want it to
Sep 24, 2015
David Nadlinger
Sep 24, 2015
Manu
Sep 29, 2015
yebblies
Sep 29, 2015
Manu
Sep 30, 2015
Iain Buclaw
Oct 03, 2015
Manu
Jun 05, 2019
Mike Franklin
Jun 05, 2019
Manu
Jun 05, 2019
Manu
Jun 06, 2020
Walter Bright
Jun 08, 2020
Manu
Dec 17, 2022
Iain Buclaw
September 24, 2015
https://issues.dlang.org/show_bug.cgi?id=15110

David Nadlinger <code@klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@klickverbot.at

--- Comment #1 from David Nadlinger <code@klickverbot.at> ---
Didn't Walter just fix an issue like this in master? The problem is probably that DMD can't/couldn't inline "if (a) return b; return c;"-type constructs.

--
September 24, 2015
https://issues.dlang.org/show_bug.cgi?id=15110

--- Comment #2 from Manu <turkeyman@gmail.com> ---
Okay. I've encountered this sort of problem a lot, it might all be the same problem though, this isn't exactly an uncommon pattern.

--
September 29, 2015
https://issues.dlang.org/show_bug.cgi?id=15110

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com

--- Comment #3 from yebblies <yebblies@gmail.com> ---
> pragma(inline) rarely works how I want it to

How exactly are you expecting pragma(inline) to work?

--
September 29, 2015
https://issues.dlang.org/show_bug.cgi?id=15110

--- Comment #4 from Manu <turkeyman@gmail.com> ---
Well, firstly, it should inline.
Secondly, it should never be an error if it's impossible to inline (it should
be a warning).

Ie, exactly like __forceinline in C++.

Also, it would be nice if it were an attribute (like GDC/LDC) so it can be
aliased.

--
September 30, 2015
https://issues.dlang.org/show_bug.cgi?id=15110

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Manu from comment #4)
> Well, firstly, it should inline.
> Secondly, it should never be an error if it's impossible to inline (it
> should be a warning).
> 

I disagree on point 2 here (it rightly should be an error).  But then again we are talking about a behaviour that can't be regulated with our current choice of compiler technologies.  So you'll have to accept that each will do it's own independent thing here.

> Ie, exactly like __forceinline in C++.
> 

There is no __forceinline in C++. :-)

--
October 03, 2015
https://issues.dlang.org/show_bug.cgi?id=15110

--- Comment #6 from Manu <turkeyman@gmail.com> ---
There are cases where it should be valid to fail inlining, but shouldn't be an
error.
For instance, if I take the address of the function, that kinda implies it
needs to emit an instance of the function... I shouldn't need to duplicate the
function just because I take a function pointer in some situation.

Another problem is that it's difficult to make all compilers inline with exactly the same behaviour, and what might work fine in one doesn't work in the other. I don't believe it's reasonable for this to emit a compile error when behaviour is different between compilers. You can't reliably build code anymore.

It should just be a warning. The user needs to know when it doesn't inline, and they can then take appropriate action, but it shouldn't stop the program from compiling. That's highly annoying, it may create mutual-exclusions with other configurations where it works fine. It may very well be a niche configuration where it doesn't work (probably, since inhibitors would be addressed in the main configuration). There's no value in making it an error, it's only annoying, and results in code that's almost certainly brittle, since you have no idea whether your code will compile without errors unless you test every possible configuration.

__forceinline/__attribute__((always_inline)). The behaviour is the same; it's a
warning when inlining fails, and it would be extremely inconvenient (to the
point of the feature being virtually useless) if it didn't behave this way.

--
June 05, 2019
https://issues.dlang.org/show_bug.cgi?id=15110

Mike Franklin <slavo5150@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slavo5150@yahoo.com

--- Comment #7 from Mike Franklin <slavo5150@yahoo.com> ---
The problem is that DMD currently ignores `pragma(inline, true)` unless the compiler is invoked with `-inline`.  I think the correct behavior is that `pragma(inline, true)` should work regardless of the presence of the `-inline` compiler flag.

--
June 05, 2019
https://issues.dlang.org/show_bug.cgi?id=15110

--- Comment #8 from Manu <turkeyman@gmail.com> ---
Right. I think `pragma(inline, true)` should express an AST inline in the front-end, and fail whenever such inlining can't occur.

--
June 05, 2019
https://issues.dlang.org/show_bug.cgi?id=15110

--- Comment #9 from Manu <turkeyman@gmail.com> ---
** error even

--
June 06, 2020
https://issues.dlang.org/show_bug.cgi?id=15110

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #10 from Walter Bright <bugzilla@digitalmars.com> ---
Manu, I thought you had argued strongly to me that if the inlining fails an error should be generated.

--
« First   ‹ Prev
1 2