search for: performancetip

...3/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...

...-a-jit-compiler https://llvm.org/docs/tutorial/WritingAnLLVMPass.html https://llvm.org/docs/tutorial/Passes.html https://llvm.org/docs/tutorial/ProgrammersManual.html#viewing-graphs-while-debugging-code https://llvm.org/docs/tutorial/SourceLevelDebugging.html https://llvm.org/docs/tutorial/Frontend/PerformanceTips.html https://llvm.org/docs/tutorial/GetElementPtr.html https://llvm.org/docs/tutorial/GarbageCollection.html https://llvm.org/docs/tutorial/ExceptionHandling.html https://www.llvm.org/docs/doxygen/structLICM.html http://llvm.org/docs/TestSuiteMakefileGuide http://llvm.org/docs/doxygen/structLICM.h...

...ve desire to avoid teaching GVN and related pieces (of which memcpyopt is one) about first class aggregates. We don't have enough active users of the feature to justify and maintain the complexity. If you haven't already seen it, this background may help: http://llvm.org/docs/Frontend/PerformanceTips.html#avoid-loads-and-stores-of-large-aggregate-type The current proposal is to convert such aggregate loads and stores into their component pieces. If that happens, you're example should come "for free" provided that the same example works when you break down the FCA into it'...

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 c...

...ames.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: > 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. First, thanks for working on this! Some things (perhaps) worth mentioning...

...related pieces (of which memcpyopt is one) about > first class aggregates. We don't have enough active users of the > feature to justify and maintain the complexity. > > If you haven't already seen it, this background may help: > http://llvm.org/docs/Frontend/PerformanceTips.html#avoid-loads-and-stores-of-large-aggregate-type > > The current proposal is to convert such aggregate loads and stores > into their component pieces. If that happens, you're example > should come "for free" provided that the same example works when >...

On Sat, 6 May 2017 13:46:18 -0700 Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm not sure that will work well, because people won't usually > > wait a week to get their questions before moving on. If you're > > actively working full time on a project, you probably want > > answers in much less time. > > Sure s/week/day/ then.

...bove in mind, I don't see it as unreasonable for frontends to > generate IR that LLVM is comfortable with. We seem fine telling frontend > authors that they should strive to avoid large aggregate memory operations > in our performance tips guide < > http://llvm.org/docs/Frontend/PerformanceTips.html#avoid-loads-and-stores-of-large-aggregate-type>. > Implementation experience with Clang hasn't shown this to be particularly > odious to follow and none of the LLVM-side solutions seem satisfactory. > > Most front end do not have clang resources. Additionally, this tip is n...

I understand these objections. They ends up being a problem at the limit (ie the example of the 64k store or 1Mb+ aggregate). These probably require their own fix or probably just shouldn't be supported. That being said, there is a vast space between what is done now and aggregate so big that it causes real hard problems like the ones you mention. reducing that gap seems like a win to me.

...as unreasonable for frontends to >>> generate IR that LLVM is comfortable with. We seem fine telling frontend >>> authors that they should strive to avoid large aggregate memory operations >>> in our performance tips guide < >>> http://llvm.org/docs/Frontend/PerformanceTips.html#avoid-loads-and-stores-of-large-aggregate-type>. >>> Implementation experience with Clang hasn't shown this to be particularly >>> odious to follow and none of the LLVM-side solutions seem satisfactory. >>> >>> >> Most front end do not have cla...

...vide strictly more aliasing information to the optimizer. > - The zext is a bit weird. I'm not sure where that came from, but I'd not > bother looking into until the preceding point is addressed. > > In general, you may find these docs useful: > http://llvm.org/docs/Frontend/PerformanceTips.html > > Philip > > > > On 02/08/2016 06:54 AM, Paul Peet via llvm-dev wrote: > > Hello, > > I am trying to emulate the "stack" as like on x86 when using push/pop so > afterwards I can use LLVM's optimizer passes to simplify (reduce junk) the > cod...

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

...: "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: >> 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. > > First, thanks for working on this! Some things...

...lvm.org/docs/tutorial/WritingAnLLVMPass.html > https://llvm.org/docs/tutorial/Passes.html > > https://llvm.org/docs/tutorial/ProgrammersManual.html#viewing-graphs-while-debugging-code > https://llvm.org/docs/tutorial/SourceLevelDebugging.html > https://llvm.org/docs/tutorial/Frontend/PerformanceTips.html > https://llvm.org/docs/tutorial/GetElementPtr.html > https://llvm.org/docs/tutorial/GarbageCollection.html > https://llvm.org/docs/tutorial/ExceptionHandling.html > https://www.llvm.org/docs/doxygen/structLICM.html > http://llvm.org/docs/TestSuiteMakefileGuide > http://llvm...

Hello, I am trying to emulate the "stack" as like on x86 when using push/pop so afterwards I can use LLVM's optimizer passes to simplify (reduce junk) the code. The LLVM IR code: define { i32, i32, i32 } @test(i32 %foo, i32 %bar, i32 %sp) { ; push foo (On "stack") %sp_1 = sub i32 %sp, 4 %sp_1_ptr = inttoptr i32 %sp_1 to i32* store i32 %foo, i32* %sp_1_ptr, align

From: Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> Date: mardi 8 septembre 2015 12:50 To: Benoit Belley <benoit.belley at autodesk.com<mailto:benoit.belley at autodesk.com>>, "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject:

...h memcpyopt is one) about first class aggregates. >>> We don't have enough active users of the feature to justify and maintain >>> the complexity. >>> >>> If you haven't already seen it, this background may help: >>> http://llvm.org/docs/Frontend/PerformanceTips.html#avoid- >>> loads-and-stores-of-large-aggregate-type >>> >>> The current proposal is to convert such aggregate loads and stores into >>> their component pieces. If that happens, you're example should come "for >>> free" provided that...

...ough, even more people could be using LLVM to create compilers, which would be a great thing. And, selfishly, given better resources, my own work would be easier. :) Thus my overall interest. > However, I liked your idea of maintaining a wiki-like thing. Both > http://llvm.org/docs/Frontend/PerformanceTips.html and > http://llvm.org/docs/tutorial/ will be good additions there. Parts of the programmer's manual http://llvm.org/docs/ProgrammersManual.html are also essential, though for a front end developer, especially one using the C API, not everything is something you want to know, and it is...

Hello all, I'm trying to find the pass that would convert from: define void @main(%struct* byval %ptr) { %val = load %struct* %ptr %val.ptr = alloca %struct store %struct %val, %struct* %val.ptr call void @extern_func(%struct* byval %val.ptr) ret void } to this: define void @main(%struct* byval %ptr) { call void @extern_func(%struct* byval %ptr) ret void } First, am I missing

...to the optimizer. >>> - The zext is a bit weird. I'm not sure where that came from, but I'd >>> not bother looking into until the preceding point is addressed. >>> >>> In general, you may find these docs useful: >>> http://llvm.org/docs/Frontend/PerformanceTips.html >>> >>> Philip >>> >>> >>> >>> On 02/08/2016 06:54 AM, Paul Peet via llvm-dev wrote: >>> >>> Hello, >>> >>> I am trying to emulate the "stack" as like on x86 when using push/pop so >>>...