search for: inlinecost

Hi, After r256521 - which removes InlineCostAnalysis class - I think there is no strong reason for InlineCost.cpp to be part of the Analysis library. Is it fine to make it part of TransformUtils? I submitted r266477 (which has now been reverted) that made Analysis depend on ProfileData in order to obtain ProfileSummary for the module, but t...

...andler Carruth" <chandlerc at gmail.com>, "Hal Finkel" <hfinkel at anl.gov>, "Philip Reames" >> <listmail at philipreames.com>, "David Li" <davidxl at google.com> >> Sent: Monday, April 18, 2016 2:39:49 PM >> Subject: Move InlineCost.cpp out of Analysis? >> >> >> Hi, >> >> >> After r256521 - which removes InlineCostAnalysis class - I think >> there is no strong reason for InlineCost.cpp to be part of the >> Analysis library. Is it fine to make it part of TransformUtils? >&g...

...> about what the code *does*. > > Code for mutating the IR should be in Transforms, and code that analyzes > the IR without mutating it should be in Analysis. This is why, for example, > InstructionSimplify is in Analysis -- it does not mutate the IR in any way. > > So I think InlineCost and similar things should stay in the Analysis > library regardless of whether they are passes or not. > Is that the only criteria (IR mod or not) ? Most of the transformations have pass specific analysis (that are not shared with other clients) -- those code stay with the transformation --...

...lude -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../libdecnumber -I/home/gautam/code/llvm/llvm_install/include -I/home/gautam/code/llvm/llvm/include -DL_gcov -c ../../trunk/gcc/libgcov.c -o libgcc/./_gcov.o cc1: /home/gautam/code/llvm/llvm/include/llvm/Transforms/Utils/InlineCost.h:44: llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost exceeds InlineCost precision"' failed. ../../trunk/gcc/libgcov.c:644: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://devel...

...ine cost; the code that calculates the inline cost generates a cost that is too large, and so you hit the assertion. I haven't yet distilled a test case for this yet (had some problems with bugpoint for some mysterious reason), but I do have a work-around: go into include/llvm/Transforms/Utils/InlineCost.h and make the following change: Index: InlineCost.h =================================================================== --- InlineCost.h (revision 66848) +++ InlineCost.h (working copy) @@ -37,8 +37,13 @@ Never }; +#if 0 int Cost : 30; unsigned Type : 2; +#e...

...e *does*. >> >> Code for mutating the IR should be in Transforms, and code that analyzes >> the IR without mutating it should be in Analysis. This is why, for example, >> InstructionSimplify is in Analysis -- it does not mutate the IR in any way. >> >> So I think InlineCost and similar things should stay in the Analysis >> library regardless of whether they are passes or not. >> > > Is that the only criteria (IR mod or not) ? Most of the transformations > have pass specific analysis (that are not shared with other clients) -- > those code stay...

...lates the > inline cost generates a cost that is too large, and so you hit the > assertion. > > I haven't yet distilled a test case for this yet (had some problems with > bugpoint for some mysterious reason), but I do have a work-around: go > into include/llvm/Transforms/Utils/InlineCost.h and make the following > change: > > > Index: InlineCost.h > =================================================================== > --- InlineCost.h (revision 66848) > +++ InlineCost.h (working copy) > @@ -37,8 +37,13 @@ > Never > }; > >...

There's a problem with LLVM version 2.5 compiled under G++ 4.1.2 which involves computing the cost of inlining a function. It works fine in a debug build. However, the Release build seems to tickle a g++ bug. Here is the code, from InlineCost.h: class InlineCost { enum Kind { Value, Always, Never }; int Cost : 30; unsigned Type : 2; InlineCost(int C, int T) : Cost(C), Type(T) { assert(Cost == C && "Cost exceeds InlineCost precision"); } If the cost C is negative, t...

...i" <davidxl at google.com> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "Hal Finkel" > <hfinkel at anl.gov>, "via llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, April 18, 2016 4:31:05 PM > Subject: Re: [llvm-dev] Move InlineCost.cpp out of Analysis? > On Mon, Apr 18, 2016 at 2:28 PM Xinliang David Li < > davidxl at google.com > wrote: > > On Mon, Apr 18, 2016 at 2:18 PM, Chandler Carruth < > > chandlerc at gmail.com > wrote: > > > > The difference between Analysis and Transform...

...<hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "via llvm-dev" > <llvm-dev at lists.llvm.org>, "Xinliang David Li" <davidxl at google.com> > Sent: Monday, April 18, 2016 4:54:36 PM > Subject: Re: [llvm-dev] Move InlineCost.cpp out of Analysis? > On Mon, Apr 18, 2016 at 2:46 PM Hal Finkel < hfinkel at anl.gov > wrote: > > > From: "Chandler Carruth" < chandlerc at gmail.com > > > > > > > To: "Xinliang David Li" < davidxl at google.com > > >...

...e/gcc/../libcpp/include -I../../llvm-gcc4.2-2.5.source/gcc/../libdecnumber -I../libdecnumber -I/pkg/build/llvm/llvm-obj//include -I/pkg/build/llvm/llvm-2.5/include -DL_gcov -c ../../llvm-gcc4.2-2.5.source/gcc/libgcov.c -o libgcc/./_gcov.o cc1: /pkg/build/llvm/llvm-2.5/include/llvm/Transforms/Utils/InlineCost.h:44: llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost exceeds InlineCost precision"' failed. ../../llvm-gcc4.2-2.5.source/gcc/libgcov.c:644: internal compiler error: Aborted So I tried this config for llvm-gcc: $ ../llvm-gcc4.2-2.5.source/configure --pr...

...rates a cost that is too large, and so you hit the >> assertion. >> >> I haven't yet distilled a test case for this yet (had some problems >> with >> bugpoint for some mysterious reason), but I do have a work-around: go >> into include/llvm/Transforms/Utils/InlineCost.h and make the >> following >> change: Glad that works for you, but it means that if the 32-bit cost computation overflows, we won't be told about it. I think the right thing is to make sure the computation saturates at 30 bits instead of overflowing. Am I going to talk...

Hi all, I am a new user of LLVM, and wanted to explore it in conjunction with the compilers course I am taking in my university. To this end, I downloaded the code for the LLVM suite and the LLVM-gcc front end from the respective repositories. Then, I built the LLVM suite without any hitch, but when I tried to build the llvm-gcc frontend (exactly following the instructions of README.LLVM) , I got

...but now I am getting a different > error. On running make, the output ends with the following error: please don't only reply to me, please reply to the list too. That way others can comment, and the discussion is archived. > cc1: /home/gautam/code/llvm/llvm/include/llvm/Transforms/Utils/InlineCost.h:44: > llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost > exceeds InlineCost precision"' failed. > ../../trunk/gcc/libgcov.c:644: internal compiler error: Aborted > Please submit a full bug report, your system compiler is broken, this is a kn...

Hi, > cc1: /pkg/build/llvm/llvm-2.5/include/llvm/Transforms/Utils/InlineCost.h:44: > llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost > exceeds InlineCost precision"' failed. > ../../llvm-gcc4.2-2.5.source/gcc/libgcov.c:644: internal compiler error: Aborted this is indeed a miscompilation by your system compiler. However...

Hi, the versions of llvm-gcc and llvm you are using are not synchronized. Probably one is from subversion while the other is not. Ciao, Duncan.

...s pass in all likelihood) that brokers >> access to these annotations through an API that can do intelligent things >> like synthesizing it from the "cold" attribute or whatever when missing. >> >> > Invariants b) and c) above are still true, but a) is not since InlineCost > directly calls ProfileSummary instead of through an analysis pass. > Not quite -- ProfileSummary seems to only exist in the profile *reading* code, so it isn't *just* an annotation on the IR. I think the problem here is that we have failed to build a proper separate abstraction around...

..." <chandlerc at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "via llvm-dev" > <llvm-dev at lists.llvm.org>, "Mehdi Amini" <mehdi.amini at apple.com> > Sent: Monday, April 18, 2016 5:45:21 PM > Subject: Re: [llvm-dev] Move InlineCost.cpp out of Analysis? > On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth < > chandlerc at gmail.com > wrote: > > On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel < hfinkel at anl.gov > > > wrote: > > > > > From: "Xinliang David Li" < davidxl a...

On Mon, Apr 18, 2016 at 4:38 PM Xinliang David Li <davidxl at google.com> wrote: > >>>> Now, the original design only accounted for profile information >>>> *within* a function body, clearly it needs to be extended to support >>>> intraprocedural information. >>>> >>> >>> >>> Not sure what you mean. Profile data

...ul> + <li><tt>llvm/Support/AIXDataTypesFix.h</tt> to <tt>llvm/System/AIXDataTypesFix.h</tt></li> + <li><tt>llvm/Support/DataTypes.h</tt> to <tt>llvm/System/DataTypes.h</tt></li> + <li><tt>llvm/Transforms/Utils/InlineCost.h</tt> to <tt>llvm/Analysis/InlineCost.h</tt></li> + <li><tt>llvm/Support/Mangler.h</tt> to <tt>llvm/Target/Mangler.h</tt></li> + <li><tt>llvm/Analysis/Passes.h</tt> to <tt>llvm/CodeGen/Passes.h</tt></li&...