You may have noticed I added an "inlinehint" attribute to the IR
yesterday, to represent user declarations that hint inlining would be
a good idea ("inline" keyword). Chris and I have been discussing how
to hook it up to the C++ FE. Consider:
class X {
int A(int x) {....}
inline int B(int x);
};
inline int X::B(int x) {...}
Per the language standard, A and B are semantically identical, both
"inline". It's been suggested that we should omit the inlinehint
on
A, on the grounds that many C++ programmers do not know this, and
therefore misuse the construct. I want to get some other views on
this. Do you think it's a good idea?
(For those of you who consider yourselves C++ programmers - and not FE
language lawyers, who are supposed to know what the standard says -
did you know this?)
On Aug 26, 2009, at 10:59 AM, Dale Johannesen wrote:> You may have noticed I added an "inlinehint" attribute to the IR > yesterday, to represent user declarations that hint inlining would be > a good idea ("inline" keyword). Chris and I have been discussing how > to hook it up to the C++ FE. Consider: > > class X { > int A(int x) {....} > inline int B(int x); > }; > inline int X::B(int x) {...} > > Per the language standard, A and B are semantically identical, both > "inline". It's been suggested that we should omit the inlinehint on > A, on the grounds that many C++ programmers do not know this, and > therefore misuse the construct.On the other hand, many C++ programmers know this and therefore omit the "inline" as redundant :)> I want to get some other views on > this. Do you think it's a good idea?Yes, I think it is a good idea. Having the "inlinehint" attribute directly tied to the "inline" keyword is easy for users to reason about, and we'll still have heuristics to inline simple functions like accessors. - Doug
On Aug 26, 2009, at 10:59 AM, Dale Johannesen wrote:> You may have noticed I added an "inlinehint" attribute to the IR > yesterday, to represent user declarations that hint inlining would be > a good idea ("inline" keyword). Chris and I have been discussing how > to hook it up to the C++ FE. Consider: > > class X { > int A(int x) {....} > inline int B(int x); > }; > inline int X::B(int x) {...} > > Per the language standard, A and B are semantically identical, both > "inline". It's been suggested that we should omit the inlinehint on > A, on the grounds that many C++ programmers do not know this, and > therefore misuse the construct. I want to get some other views on > this. Do you think it's a good idea? > (For those of you who consider yourselves C++ programmers - and not FE > language lawyers, who are supposed to know what the standard says - > did you know this?)I recommend following the C++ standard here. Just as there are codebases where the inline keyword is added to function definitions inside class bodies with the intent to be meaningful, there are also codebases where the inline keyword is omitted as redundant. LLVM itself is one of the latter, for the most part. For this reason, I'm actually somewhat surprised that you're adding this hint, because you'll still need heuristics to find functions to inline that aren't hinted, and to ignore hints on functions which aren't good candidates. Are you aiming to create inlining heuristics modeled after those of another compiler? If so, should the answer be "whatever that other compiler does?" Dan
Dale Johannesen <dalej at apple.com> writes: [snip]> Per the language standard, A and B are semantically identical, both > "inline". It's been suggested that we should omit the inlinehint on > A, on the grounds that many C++ programmers do not know this, and > therefore misuse the construct. I want to get some other views on > this. Do you think it's a good idea? > (For those of you who consider yourselves C++ programmers - and not FE > language lawyers, who are supposed to know what the standard says - > did you know this?)Maybe I'm not understanding your question, but for me methods defined inside the class definition are inline and I would be dissapointed if the compiler thinks otherwise (unless it knows that inlining would cause inferior performance or is technically unfeasible: the Borland compiler used to refuse inlining on some circunstances, such as when the function contained a `throw'). After all, `inline' is like `register': just a wish that the compiler can ignore, but a compiler shouldn't disregard the standard just for not creating surprises to uninformed users, IMO. -- Óscar
On Aug 26, 2009, at 11:18 AMPDT, Dan Gohman wrote:> For this reason, I'm actually somewhat surprised that you're adding > this hint, because you'll still need heuristics to find functions to > inline that aren't hinted, and to ignore hints on functions which > aren't good candidates. Are you aiming to create inlining heuristics > modeled after those of another compiler? If so, should the answer be > "whatever that other compiler does?"Not necessarily, I'm going to be experimenting. A compiler can't possibly do optimal inlining without help, since the right inlining choices depend heavily on which calls and functions actually get executed, and the compiler can't know that. The inline hint is there in the languages so the inliner can give higher priority to inlining functions so marked; it seems advisable to make it available to our inliner. It may be that people misuse it so badly that it's ineffective, although I doubt that.
On Wed, Aug 26, 2009 at 10:59 AM, Dale Johannesen<dalej at apple.com> wrote:> You may have noticed I added an "inlinehint" attribute to the IR > yesterday, to represent user declarations that hint inlining would be > a good idea ("inline" keyword). Chris and I have been discussing how > to hook it up to the C++ FE. Consider: > > class X { > int A(int x) {....} > inline int B(int x); > }; > inline int X::B(int x) {...} > > Per the language standard, A and B are semantically identical, both > "inline". It's been suggested that we should omit the inlinehint on > A, on the grounds that many C++ programmers do not know this, and > therefore misuse the construct. I want to get some other views on > this. Do you think it's a good idea? > (For those of you who consider yourselves C++ programmers - and not FE > language lawyers, who are supposed to know what the standard says - > did you know this?)I do not understand how the "inlinehint" will help. How will it influence the inliner ? - Devang
On Aug 26, 2009, at 11:54 AMPDT, Devang Patel wrote:> On Wed, Aug 26, 2009 at 10:59 AM, Dale Johannesen<dalej at apple.com> > wrote: >> You may have noticed I added an "inlinehint" attribute to the IR >> yesterday, to represent user declarations that hint inlining would be >> a good idea ("inline" keyword). Chris and I have been discussing how >> to hook it up to the C++ FE. Consider: >> >> class X { >> int A(int x) {....} >> inline int B(int x); >> }; >> inline int X::B(int x) {...} >> >> Per the language standard, A and B are semantically identical, both >> "inline". It's been suggested that we should omit the inlinehint on >> A, on the grounds that many C++ programmers do not know this, and >> therefore misuse the construct. I want to get some other views on >> this. Do you think it's a good idea? >> (For those of you who consider yourselves C++ programmers - and not >> FE >> language lawyers, who are supposed to know what the standard says - >> did you know this?) > > I do not understand how the "inlinehint" will help. How will it > influence the inliner ?The hint should make it more attractive to inline. I don't know the details yet and they will require some experimenting.
On Wednesday 26 August 2009 12:59, Dale Johannesen wrote:> class X { > int A(int x) {....} > inline int B(int x); > }; > inline int X::B(int x) {...} > > Per the language standard, A and B are semantically identical, both > "inline". It's been suggested that we should omit the inlinehint on > A, on the grounds that many C++ programmers do not know this, and > therefore misuse the construct.No, no, no! :) I rely on this behavior. I assume anything I define in the class definition will be inlined (when reasonable). I do this for performance reasons. -Dave
On Thu, Aug 27, 2009 at 6:00 PM, David Greene<dag at cray.com> wrote:> On Wednesday 26 August 2009 12:59, Dale Johannesen wrote: > >> class X { >> int A(int x) {....} >> inline int B(int x); >> }; >> inline int X::B(int x) {...} >> >> Per the language standard, A and B are semantically identical, both >> "inline". It's been suggested that we should omit the inlinehint on >> A, on the grounds that many C++ programmers do not know this, and >> therefore misuse the construct. > > No, no, no! :) I rely on this behavior. I assume anything I define > in the class definition will be inlined (when reasonable). I do this for > performance reasons.I would say that I am a new and inexpert C++ programmer, and I always thought the idea of putting methods in headers was not a way of saying to the compiler "please inline this" but rather a way to expose it to the compiler so that it would be possible to inline. When writing templates or helper classes, I've always written the methods inline in the class definition because it creates less duplication. If you're coming from Java, this style is of course natural. So to answer Dale's original question, I would guess that most inexpert C++ programmers expect that if they define a method inline, then they are not telling the compiler it should be inlined, but that the compiler should use its heuristics to decide if it should be. Reid