similar to: [LLVMdev] RFC: PerfGuide for frontend authors

I'm moving forward with this now given no one has raised objections. Based on Sean's comments, the naming I'm going to use is: FrontendInfo/PerfTips I plan on committing an initial version based on what was discussed here without further review. I'm going to keep the first version short, and then open it for others to contribute. Philip On 02/24/2015 02:13 PM, Sean Silva

Just to be clear, you mean the release notes for 3.7 not 3.6 right? On 03/04/2015 02:15 PM, Hans Wennborg wrote: > This is great. Can you add it to the release notes? > > On Fri, Feb 27, 2015 at 3:34 PM, Philip Reames > <listmail at philipreames.com> wrote: >> The first version of this document is now live: >> http://llvm.org/docs/Frontend/PerformanceTips.html

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, February 27, 2015 5:34:36 PM > Subject: Re: [LLVMdev] RFC: PerfGuide for frontend authors > > The first version of this document is now live: >

The first version of this document is now live: http://llvm.org/docs/Frontend/PerformanceTips.html Please feel free to add to it directly. Alternatively, feel free to reply to this thread with text describing an issue that should be documented. I'll make sure text gets turned into patches. Philip On 02/23/2015 04:46 PM, Philip Reames wrote: > I'd like to propose that we create a

> On Feb 27, 2015, at 3:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> From: "Philip Reames" <listmail at philipreames.com> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, February 27, 2015 5:34:36 PM >> Subject: Re: [LLVMdev] RFC: PerfGuide for frontend

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, February 27, 2015 11:25:12 PM > Subject: Re: [LLVMdev] RFC: PerfGuide for frontend authors > > > > On Feb 27, 2015, at

I will second point #1 above. It bit me. May I suggest that for each of these, something is said (ideally an example) of how to do these things using the API? It's pretty straightforward when writing IR assembly, but not so obvious when you're building up the IR using the various calls to methods defined in include/llvm/IR. It might also be worthwhile to add information on how to

I'd like to propose that we add an attribute which expresses the notion that the specified value is /either/ null or dereferenceable up to a fixed size. (Note the xor.) Our current dereferenceable(n) attribute doesn't quite fit the bill, it implies that the pointer is non-null. Similarly, our nonnull attribute says nothing about dereferenceability. There are two syntax proposals

On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > Hi, > > On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >> ----- Original Message ----- >>> From: "Philip Reames" <listmail at philipreames.com> >>>> 6. Use the lifetime.start/lifetime.end and >>>> invariant.start/invariant.end intrinsics where possible >>> Do you find these

Hi, On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Philip Reames" <listmail at philipreames.com> > > > 6. Use the lifetime.start/lifetime.end and > > > invariant.start/invariant.end intrinsics where possible > > Do you find these help in practice? The few experiments I ran were > > neutral at best

> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > >> On 2015.02.28 14:23:02 -0800, Philip Reames wrote: >>> On 02/28/2015 10:04 AM, Björn Steinbrink wrote: >>> Hi, >>> >>>> On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >>>> ----- Original Message ----- >>>>> From: "Philip

On 2015.02.28 14:23:02 -0800, Philip Reames wrote: > On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > >Hi, > > > >On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: > >>----- Original Message ----- > >>>From: "Philip Reames" <listmail at philipreames.com> > >>>>6. Use the lifetime.start/lifetime.end and >

[This time without dropping the list, sorry] 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: >> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >> >>> On 2015.02.28 14:23:02 -0800, Philip Reames wrote: >>>> On 02/28/2015 10:04 AM, Björn Steinbrink wrote: >>>> Hi, >>>>

Hi everyone, Nick and Philip suggested something yesterday that I'd also thought about: supporting attributes on values (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140908/234323.html). The primary motivation for this is to provide a way of attaching pointer information, such as noalias, nonnull and dereferenceable(n), to pointers generated by loads. Doing this for pointers

I think calling the attribute "used" is confusing. I'd suggest the following: "not_poison": If an argument is marked not_poison, and the argument is poison at runtime, the call is instant UB. Whether an argument is poison is checked after the rules for other attributes like "nonnull" and "align" are applied. This makes it clear that the IR semantics

> On Feb 28, 2015, at 3:01 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > > [This time without dropping the list, sorry] > > 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: > >>>> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >>>> >>>>> On 2015.02.28

Hi Johannes, >> Not sure the semantics of "used" you propose is sufficient. AFAIU the >> proposal, "used" could only be used in cases where the function will >> always trigger UB if poison is passed as argument. The semantics of >> attributes is usually the other way around, since function calls need >> to have UB as strong as the worst

Hello all, LangRef says it is undefined behavior to pass null to a nonnull argument (`call f(nonnull null);`), but the semantics is too strong for a few existing optimizations. To support these, we can relax the semantics so `f(nonnull null)` is equivalent to `f(poison)`, but (A) it again blocks another set of optimizations, and (B) this makes the semantics of nonnull deviate from other

> On Mar 1, 2015, at 7:53 AM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > > On 2015.02.28 18:17:27 -0800, Philip Reames wrote: >>> On Feb 28, 2015, at 3:01 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >>> 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: >>>>>> On Feb 28, 2015, at 2:30 PM, Björn

Hi all, I would like to propose a new way clang would decorate vtable loads in order to handle devirtualization better. I've added *llvm-dev* also, because this can start a discussion about changing invariant.group to just invariant. PDF version of this RFC can be found here: https://drive.google.com/file/d/0B72TmzNsY6Z8ZmpOUnB5dDZfSFU/view?usp=sharing Background: Initial old design: