similar to: ThinLTO status in trunk?

> On Jul 22, 2016, at 12:36 PM, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Vikram, > > Thanks! > > I'm not sure what part got committed in the 3.8 timeframe - it looks like that was released back in March? 3.8 was branched in early January though. It has some of the work-in-progress for ThinLTO, it “could” work in simple cases I

Hi Teresa, Impressive results, indeed! (But no less is expected from an Itanium alumni... ;-)) One question, if you don't mind. In the blog post you wrote: "In a few cases ThinLTO even outperforms full LTO, most likely because the higher scalability of ThinLTO allows using a more aggressive backend optimization pipeline (similar to that of a non-LTO build)." Is it due to

On Fri, Dec 12, 2014 at 1:59 PM, Diego Novillo <dnovillo at google.com> wrote: > On 12/12/14 15:56, Adve, Vikram Sadanand wrote: >> >> I've been asked how LTO in LLVM compares to equivalent capabilities >> in GCC. How do the two compare in terms of scalability? And >> robustness for large applications? > > > Neither GCC nor LLVM can handle our

I've been asked how LTO in LLVM compares to equivalent capabilities in GCC. How do the two compare in terms of scalability? And robustness for large applications? Also, are there any ongoing efforts or plans to improve LTO in LLVM in the near future? Any information would be much appreciated. Thanks, --Vikram S. Adve Visiting Professor, Computer Science, EPFL Professor, Department of

(repost the reply using my personal account -- previous reply to the list got hold up) On Thu, Dec 25, 2014 at 11:55 PM, Adve, Vikram Sadanand <vadve at illinois.edu> wrote: > Diego, Teresa, David, > > Sorry for my delayed reply; I left for vacation right after sending my message about this. > > Diego, it wasn't explicit from your message whether LLVM LTO can handle

Hi Mehdi, Yes, we did see your earlier post. Efficient (de)serialization is definitely important for both exporting (a la LTO and ThinLTO) and for shipping code as IR. I expect most use cases of the latter would benefit. -—Vikram // Vikram S. Adve // Professor, Department of Computer Science // University of Illinois at Urbana-Champaign // vadve at illinois.edu<mailto:vadve at

Hi Vikram, It is a bit more that just “efficient (de)serialization” as there is some amount of tradeoff to make between “size” vs “speed” vs “flexibility” (which are all some sort of “efficient”). For instance what if we get a faster deserialization but got larger size? That might be an issue for some people who’d like to ship bitcode. Another thing is that we may get better speed/size by

Dear All, Here's a question Vikram and I received. Is the LLVM JIT thread safe? -- John T. -------------- next part -------------- An embedded message was scrubbed... From: "Adve, Vikram Sadanand" <vadve at uiuc.edu> Subject: Fwd: LLVM and threading Date: Thu, 1 Nov 2007 09:48:59 -0500 Size: 3037 URL:

I'm trying to decide whether to use either the MIPS or ARM back ends for course projects in our introductory compiler class. I'd like to use something that has a stable back end, so that the students can use the selector, probably without changes, and do a project on register allocation and stack layout. We don't have MIPS or ARM hardware (other than possibly a few donated Android

> On Jan 20, 2017, at 10:44 AM, Tian, Xinmin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sanjoy, the IR would be like something below. It is ok to hoist alloca instruction outside the region. There are some small changes in optimizer to understand region-annotation intrinsic. > > { void main() { > i32* val = alloca i32 > tok =

In this case, inliner is educated to add all local variables to the tag of enclosing parallel region, if there is enclosing parallel region. In our icc implementation, it is even simple, as we have routine level symbol table, the inliner adds ”private” attribute to those local variables w/o checking enclosing scope, the parallelizer does check and use it. Xinmin From: mehdi.amini at apple.com

From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Tuesday, January 31, 2017 9:03 PM To: Tian, Xinmin <xinmin.tian at intel.com> Cc: Sanjoy Das <sanjoy at playingwithpointers.com>; Adve, Vikram Sadanand <vadve at illinois.edu>; llvm-dev at lists.llvm.org; llvm-dev-request at lists.llvm.org Subject: Re: [llvm-dev] [RFC] IR-level Region Annotations On Jan 31,

> On Jan 31, 2017, at 7:53 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > > In this case, inliner is educated to add all local variables to the tag of enclosing parallel region, if there is enclosing parallel region. So isn’t it a good example that shows that your intrinsic *cannot* be opaque and that IR passes need to be modified to handle not only the IR-region

> On Jan 31, 2017, at 5:38 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > >>>>> Ok, but this looks like a “workaround" for your specific use-case, I don’t see how it can scale as a model-agnostic and general-purpose region semantic. > > I would say it is a design trade-off. I’m not sure if we’re talking about the same thing here: my understanding at

> On Jan 31, 2017, at 10:59 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > > >   <> > From: mehdi.amini at apple.com <mailto:mehdi.amini at apple.com> [mailto:mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>] > Sent: Tuesday, January 31, 2017 9:03 PM > To: Tian, Xinmin <xinmin.tian at intel.com <mailto:xinmin.tian at

Hi Sanjoy, Yes, that's exactly what we have been looking at recently here, but the region tags seem to make it possible to express the control flow as well, so I think we could start with reg ions+metadata, as Hal and Xinmin proposed, and then figure out what needs to be first class instructions. --Vikram Adve > On Jan 19, 2017, at 11:03 PM, Sanjoy Das <sanjoy at

> On Jan 20, 2017, at 11:17 AM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > >>>>> This means that the optimizer has to be aware of it, I’m missing the magic here? > > This is one option. > > The another option is that, as I mentioned in our LLVM-HPC paper in our implementation. We have a "prepare phase for pre-privatization" can be invoked

> On Jan 31, 2017, at 6:48 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > > Let me try this. > > You can simply consider the prepare-phase (e.g. pre-privatization) were done in FE (actually a library can be used by multiple FEs at LLVM IR level), the region is run with 1 thread, region annotation (scope, single-entry-single-exit) as memory barrier conservatively

Hal, Andrey, Alexey, >From the LLVM design viewpoint, there is a fundamental problem with both Hal's approach and the Intel approach: both are quite language-specific. OpenMP is a particular parallel language, with particular constructs (e.g., parallel regions) and semantics. LLVM is a language-neutral IR and infrastructure and OpenMP-specific concepts should not creep into it. I've

Our department outreach coordinator spotted this and forwarded it to me. It's a lot of speculation but I thought many of you would be interested. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org Begin forwarded message: > From: "Jennifer C La Montagne" <jsandone at uiuc.edu> > Date: June 8, 2007 12:53:00 PM CDT > To: "Vikram Sadanand Adve"