similar to: [LLVMdev] inlining hint

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

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

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

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".

On Wed, Aug 26, 2009 at 11:58 AM, Dale Johannesen<dalej at apple.com> wrote: > > 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

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) {....} >

On Aug 26, 2009, at 12:01 PM, Devang Patel wrote: >>> 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. >> > > In that case you want to add hint to A

On Aug 26, 2009, at 2:31 PM, David Vandevoorde wrote: > > >> I know/hope that the proposal isn't for the inlinehint to be a >> synonym >> for "force inline", it would just raise the threshold to increase the >> likeliness that it would be inlined. The question is whether >> "something being c++ inline" in any way is really

When I started this, I deliberately restricted the question to what should go in the IR. The fact of recording hints in the IR should not be controversial; it can't be better not to have them than to have them. Unfortunately, others used this as a springboard for discussing whether and how the inliner should use those hints. We aren't really ready to have that discussion,

On Wed, Aug 26, 2009 at 1:09 PM, Chris Lattner<clattner at apple.com> wrote: > I know/hope that the proposal isn't for the inlinehint to be a synonym for > "force inline", it would just raise the threshold to increase the likeliness > that it would be inlined. One alternative is to give the functions with hint first chance but not change the threshold. Inliner works

----- Original Message ----- > From: "Richard Smith" <richard at metafoo.co.uk> > To: "Xinliang David Li" <davidxl at google.com> > Cc: "cfe commits" <cfe-commits at cs.uiuc.edu>, "<llvmdev at cs.uiuc.edu> List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, July 9, 2015 3:40:54 PM > Subject: Re: [LLVMdev] Inline hint

On Wed, Aug 26, 2009 at 3:57 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > On Aug 26, 2009, at 2:31 PM, David Vandevoorde wrote: > >> >> >>> I know/hope that the proposal isn't for the inlinehint to be a >>> synonym >>> for "force inline", it would just raise the threshold to increase the >>> likeliness that it would

----- Original Message ----- > From: "Richard Smith" <richard at metafoo.co.uk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "cfe commits" <cfe-commits at cs.uiuc.edu>, "List" <llvmdev at cs.uiuc.edu>, "Xinliang David Li" <davidxl at google.com> > Sent: Thursday, July 9, 2015 8:08:38 PM > Subject: Re:

Hi Dale, Thanks for getting back. I may not be able to switch to llvm 4.2 at this time. I did try: llvm-gcc --emit-llvm -c sumarray.c -o sumarray.bc llc -march=ppc32 sumarray.bc gcc -arch ppc sumarray.s And this produced a ppc binary that worked (at least in this case). Do you know if this approach is worthwhile? Thx, Jose -----Original Message----- From: Dale Johannesen [mailto:dalej at

On Thu, 21 Feb 2008, Dale Johannesen wrote: > The defined gcc interface for this is -fno-builtin. It seems not be > to be working in llvm-gcc, however. Please file a reduced testcase in bugzilla, -Chris > >> I am interested in analyzing the bytecode code produced for C files. >> By default, inlining of user and library functions (libc) is done. If >> I turn off

It appears you filed PR 8538 about this, but didn't cc yourself. You should look at it; I don't think this is a clang problem. > It seems that the problem occurs from the optimization level. In the 2.7 > version I was using -O0 and in 2.8 I tested the same benchmarks with -O3. > > clang -O0 works fine, while clang -O3 makes redefinitions (probably it is > related to

I'm reviving this thread after a while and CCing cfe-commits as suggested by David Blaikie. I've also collected numbers building chrome (from chromium, on Linux) with and without this patch as suggested by David. I've re-posted the proposed patch and performance/size numbers collected at the top to make it easily readable for those reading it through cfe-commits. The proposed patch

On Feb 21, 2008, at 5:38 PM, Chris Lattner wrote: > On Thu, 21 Feb 2008, Dale Johannesen wrote: >> The defined gcc interface for this is -fno-builtin. It seems not be >> to be working in llvm-gcc, however. > > Please file a reduced testcase in bugzilla, > > -Chris Er, well, now that I've looked at the correct output files, it is actually working. >>> I

On Thu, Jul 9, 2015 at 7:52 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Hal Finkel" <hfinkel at anl.gov> > > To: "Richard Smith" <richard at metafoo.co.uk> > > Cc: "Xinliang David Li" <davidxl at google.com>, "cfe commits" < > cfe-commits at cs.uiuc.edu>,

Dale, Thanks. It's not changed, but I've enclosed a fresh patch against today's trunk. However, I'm seeing 28 unexpected failing tests in llvm/test on x86 Linux 64 today. But it's the same on an unmodified tree, so I guess I'm still okay. It passed at one point for me with these changes. -John On Wed, Sep 1, 2010 at 5:04 PM, Dale Johannesen <dalej at apple.com>