similar to: [LLVMdev] 2.7 release notes

Chris Lattner <clattner at apple.com> writes: > Ok, the LLVM 2.7 release notes are in near final shape. Please take > a look and suggest improvements (or, better yet, just commit > improvements if you have commit access): About the API changes, some that hit me when I ported some code to LLVM 2.7, and not in the release notes (I had sent a private email some time ago) : ---

Thanks, I must have missed these, added. On Apr 22, 2010, at 1:28 AM, Matthieu Moy wrote: > Chris Lattner <clattner at apple.com> writes: > >> Ok, the LLVM 2.7 release notes are in near final shape. Please take >> a look and suggest improvements (or, better yet, just commit >> improvements if you have commit access): > > About the API changes, some that hit

> Ok, the LLVM 2.7 release notes are in near final shape. Please take a look and suggest improvements (or, better yet, just commit improvements if you have commit access): I committed several typo fixes / rewording fixes to the release notes just now. The following paragraph under the "New Useful APIs" section needs to be reworded but I am not sure what is trying to be expressed so

Hi, Thanks for the pointers. My patch now calls the attribute "noduplicate", and updates CodeMetrics to have another field: bool notDuplicatable; Which semantically is "containsIndirectBr || containsNoDuplicateInst". I didn't repurpose containsIndirectBr because I felt what I'm looking for is sufficiently different (indirectbr inhibits inlining, whereas noduplicate

Hi all + llvm-commits, After the discussion below, please find attached my patch to add a new "noduplicate" function attribute. I've modified CodeMetrics and LoopInfo, which covers most cases, but JumpThreading and InlineCost don't use CodeMetrics yet, so they required changing manually. Cheers, James On Mon, 2012-12-03 at 23:46 +0000, Chris Lattner wrote: > On Dec 3,

On Dec 2, 2012, at 10:11 PM, Chris Lattner <clattner at apple.com> wrote: > 3) Please change random parts of the compiler to use CodeMetrics, instead of scattering random checks for this attribute throughout the code. Anything duplicating code and not using CodeMetrics is just plain incorrect. One problem that we may run into when using CodeMetrics is compile time. In many cases we

On Dec 1, 2012, at 11:49 PM, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote: > I definitely support this. > > In fact we were about to send a very similar proposal. The main difference I can see between this proposal and ours was that we named the attribute "noduplicate". > I graciously defer to James on the bikeshade color issue. Yes,

On Dec 3, 2012, at 9:48 AM, James Molloy <James.Molloy at arm.com> wrote: > Hi, > > Thanks for the pointers. My patch now calls the attribute "noduplicate", > and updates CodeMetrics to have another field: > > bool notDuplicatable; > > Which semantically is "containsIndirectBr || containsNoDuplicateInst". I > didn't repurpose

Hi Michael, After some head-scratching and discussion with our tame Khronos member, I agree with you. It comes down to the interpretation of the ambiguous spec. It refers to "the barrier", implying there is some sort of equivalence relation over barriers. The question is, what is that equivalent relation? In your example code: > void f(int foo) { > if (foo) > b();

I'm not sure I agree with the semantics this patch creates. The way I see it, there are two options: 1) Make "noduplicate" non-transitive and forbid inlining when there are multiple callsites. 2) Allow inlining, but make the attribute transitive. Consider the following code, where barrier() is marked noduplicate. kernel void k() { if (x()) y(); b(); if (x()) z();

Hi, The link "Broken versions of GCC and other tools" on http://llvm.org/docs/ReleaseNotes.html points to #brokengcc, where it should point to http://llvm.org/docs/GettingStarted.html#brokengcc I guess. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Sounds good to me. I'm not sure the solution for transitivity is optimal, but it's a good compromise. -----Original Message----- From: James Molloy [mailto:James.Molloy at arm.com] Sent: Thursday, December 06, 2012 13:05 To: Kuperstein, Michael M Cc: Chris Lattner; llvm-commits; Nadav Rotem; llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] [RFC] "noclone" function attribute Hi

Good evening, Kenneth. Thank you to apply (and rewrite my naive code better) and to file the issue to http://llvm.org/bugs/show_bug.cgi?id=7304 I have checked r105528 at this morning. I think the pass must be still cleaned up and rewritten. There are my two proposals for enhancement. 1) To separate Specialization(and rewriting callsites) to other module. It would be better if new module were

On Friday 21 September 2007, Chris Lattner wrote: > In addition to this, I've checked in the first draft of the release > notes into llvm/docs/ReleaseNotes.html (http://llvm.org/docs/ > ReleaseNotes.html). The release notes mention llvm-gcc 4.2, but the prerelease only included llvm-gcc 4.0. Is the final release going to include 4.0 or 4.2 or both? Bye, Maarten --------------

Hi All, Here is my current draft of the LLVM 2.1 release announcement. Unlike previous announcements, I'm not planning to largely duplicate the release notes in the announcement. In addition to this, I've checked in the first draft of the release notes into llvm/docs/ReleaseNotes.html (http://llvm.org/docs/ ReleaseNotes.html). I'd really appreciate it if anyone who

On Sun, Dec 2, 2012 at 10:27 PM, Nadav Rotem <nrotem at apple.com> wrote: > > On Dec 2, 2012, at 10:11 PM, Chris Lattner <clattner at apple.com> wrote: > > 3) Please change random parts of the compiler to use CodeMetrics, instead > of scattering random checks for this attribute throughout the code. > Anything duplicating code and not using CodeMetrics is just plain

> On Apr 18, 2016, at 2:07 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Easwaran Raman" <eraman at google.com> >> To: "via llvm-dev" <llvm-dev at lists.llvm.org> >> Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Hal Finkel" <hfinkel at

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 there is an existing dependency of ProfileData on

On Mon, Apr 18, 2016 at 2:18 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > The difference between Analysis and Transforms is *not* about passes, but > 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

On Fri, Mar 13, 2009 at 2:38 PM, Duncan Sands <baldrick at free.fr> wrote: > 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. > Ok, I 'synchronized' both of them, but now I am getting a different error. On running make, the output ends with the