similar to: [LLVMdev] Back ends for instructional use?

On Mon, Aug 15, 2011 at 11:20 AM, Adve, Vikram Sadanand <vadve at illinois.edu> wrote: > 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

On Aug 15, 2011, at 11:20 AM, Adve, Vikram Sadanand wrote: > 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

Hello Vikram, > 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

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:

First, kudos on the ThinLTO results reported in your blog post — they’re impressive and the system sounds really well engineered. I’m starting to try it out on a large piece of software and I’d like to make sure I know what to expect. The blog said it will be available in clang-3.9 but both clang-3.8 and trunk seem to have some degree of support for it. What is the status of ThinLTO in 3.8

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

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

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

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

> 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

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

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

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

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

> 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