Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] 2.7 release notes"
2010 Apr 22
0
[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) :
---
2010 Apr 22
1
[LLVMdev] 2.7 release notes
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
2010 Apr 22
0
[LLVMdev] 2.7 release notes
> 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
2012 Dec 03
2
[LLVMdev] [RFC] "noclone" function attribute
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
2012 Dec 04
2
[LLVMdev] [RFC] "noclone" function attribute
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,
2012 Dec 03
0
[LLVMdev] [RFC] "noclone" function attribute
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
2012 Dec 03
3
[LLVMdev] [RFC] "noclone" function attribute
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,
2012 Dec 03
0
[LLVMdev] [RFC] "noclone" function attribute
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
2012 Dec 06
2
[LLVMdev] [RFC] "noclone" function attribute
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();
2012 Dec 06
0
[LLVMdev] [RFC] "noclone" function attribute
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();
2009 Nov 03
1
[LLVMdev] Broken link on http://llvm.org/docs/ReleaseNotes.html#brokengcc
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/
2012 Dec 07
0
[LLVMdev] [RFC] "noclone" function attribute
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
2010 Jun 08
1
[LLVMdev] the PartialSpecialization pass (was Re: Is there a "callback optimization"?)
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
2007 Sep 21
0
[LLVMdev] llvm 2.1 announcement draft
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
--------------
2007 Sep 21
4
[LLVMdev] llvm 2.1 announcement draft
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
2012 Dec 03
1
[LLVMdev] [RFC] "noclone" function attribute
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
2016 Apr 18
5
Move InlineCost.cpp out of Analysis?
> 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
2016 Apr 18
2
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?
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
2016 Apr 18
5
Move InlineCost.cpp out of Analysis?
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
2009 Mar 13
2
[LLVMdev] [LLVMDev] trouble building gcc-frontend from source
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