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 >> >> 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 new Performance Guide document. The >>> target of this document will be frontend authors, not necessarily LLVM >>> contributors. The content will be a collection of items a frontend author >>> might want to know about how to generate LLVM IR which will optimize well. >>> >>> Some ideas on topics that might be worthwhile: >>> - Prefer sext over zext when value is known to be positive in the language >>> (e.g. range checked index on a GEP) >>> - Avoid loading and storing first class aggregates (i.e. they're not well >>> supported in the optimizer) >>> - Mark invariant locations - i.e. link to !invariant.load and TBAA >>> constant flags >>> - Use globals not inttoptr for runtime structures - this gives you >>> dereferenceability information >>> - Use function attributes where possible (nonnull, deref, etc..) >>> - Be ware of ordered and atomic memory operations (not well optimized), >>> depending on source language, might be faster to use fences. >>> - Range checks - make sure you test with the IRCE pass >>> >>> If folks are happy with the idea of having such a document, I volunteer to >>> create version 0.1 with one or two items. After that, we can add to it as >>> folks encounter ideas. The initial content will be fairly minimal, I just >>> want a link I can send to folks in reviews to record comments made. :) >>> >>> Philip >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Yes, 3.7. On Wed, Mar 4, 2015 at 2:55 PM, Philip Reames <listmail at philipreames.com> wrote:> 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 >>> >>> 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 new Performance Guide document. The >>>> target of this document will be frontend authors, not necessarily LLVM >>>> contributors. The content will be a collection of items a frontend >>>> author >>>> might want to know about how to generate LLVM IR which will optimize >>>> well. >>>> >>>> Some ideas on topics that might be worthwhile: >>>> - Prefer sext over zext when value is known to be positive in the >>>> language >>>> (e.g. range checked index on a GEP) >>>> - Avoid loading and storing first class aggregates (i.e. they're not >>>> well >>>> supported in the optimizer) >>>> - Mark invariant locations - i.e. link to !invariant.load and TBAA >>>> constant flags >>>> - Use globals not inttoptr for runtime structures - this gives you >>>> dereferenceability information >>>> - Use function attributes where possible (nonnull, deref, etc..) >>>> - Be ware of ordered and atomic memory operations (not well optimized), >>>> depending on source language, might be faster to use fences. >>>> - Range checks - make sure you test with the IRCE pass >>>> >>>> If folks are happy with the idea of having such a document, I volunteer >>>> to >>>> create version 0.1 with one or two items. After that, we can add to it >>>> as >>>> folks encounter ideas. The initial content will be fairly minimal, I >>>> just >>>> want a link I can send to folks in reviews to record comments made. :) >>>> >>>> Philip >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Done. On 03/04/2015 02:58 PM, Hans Wennborg wrote:> Yes, 3.7. > > On Wed, Mar 4, 2015 at 2:55 PM, Philip Reames <listmail at philipreames.com> wrote: >> 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 >>>> >>>> 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 new Performance Guide document. The >>>>> target of this document will be frontend authors, not necessarily LLVM >>>>> contributors. The content will be a collection of items a frontend >>>>> author >>>>> might want to know about how to generate LLVM IR which will optimize >>>>> well. >>>>> >>>>> Some ideas on topics that might be worthwhile: >>>>> - Prefer sext over zext when value is known to be positive in the >>>>> language >>>>> (e.g. range checked index on a GEP) >>>>> - Avoid loading and storing first class aggregates (i.e. they're not >>>>> well >>>>> supported in the optimizer) >>>>> - Mark invariant locations - i.e. link to !invariant.load and TBAA >>>>> constant flags >>>>> - Use globals not inttoptr for runtime structures - this gives you >>>>> dereferenceability information >>>>> - Use function attributes where possible (nonnull, deref, etc..) >>>>> - Be ware of ordered and atomic memory operations (not well optimized), >>>>> depending on source language, might be faster to use fences. >>>>> - Range checks - make sure you test with the IRCE pass >>>>> >>>>> If folks are happy with the idea of having such a document, I volunteer >>>>> to >>>>> create version 0.1 with one or two items. After that, we can add to it >>>>> as >>>>> folks encounter ideas. The initial content will be fairly minimal, I >>>>> just >>>>> want a link I can send to folks in reviews to record comments made. :) >>>>> >>>>> Philip >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>