similar to: [LLVMdev] TBAA: Propagating aliasing information to derived pointers

On Wed, Jan 18, 2012 at 6:13 PM, Johan Tibell <johan.tibell at gmail.com> wrote: > Hi, > > While adding support for TBAA to GHC's LLVM backend, we ran into the > following issue: given a pointer that we know has certain aliasing > properties (e.g. it points to the stack, not the heap) we'd like to > >  * annotate all loads and stores to that pointer with a TBAA

On Wed, Jan 18, 2012 at 6:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jan 18, 2012 at 6:13 PM, Johan Tibell <johan.tibell at gmail.com> wrote: >> While adding support for TBAA to GHC's LLVM backend, we ran into the >> following issue: given a pointer that we know has certain aliasing >> properties (e.g. it points to the stack, not the heap)

Hi all, I do a little work on the GHC haskell compiler. One of the things I do is compile current GHC git HEAD against the next release of LLVM to find issues and adapt the GHC code as early as possible. A recent modification to LLVM is now rejecting GHC generated LLVM IR that was previously accepted. I discussed this on IRC with sanjoyd who explained what had changed and gave me some hints

> It looks fairly likely llvm will accept arbitrary expressions as > aliasees again (see thread on llvmdev), but the restrictions inherent > from what alias are at the object level will remain, just be reworded > a bit. For example, we will have something along the lines of "the > aliasee expression cannot contain an undefined GlobalValue". And this is in: r210062. Let

In some language implementations, such as the Glasgow Haskell Compiler (GHC) and the reference implementation of Go, a thread’s stack is allocated as a data structure on the garbage-collected heap.  The garbage collector is free to move this data structure whenever it is invoked. Currently, GHC’s LLVM backend does not use the C stack.  However, there have been discussions about whether using the

Hi all, I'm hitting a segfault in llc when trying to build GHC: http://sprunge.us/ZVGB. What is the best way to debug this? I'm able to bump to 3.8.1 if needed, but GHC tends to break when updating major versions due to IR incompatibilities. Thanks, Shea -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size:

Peter: Please feel free to correct me if there are any inaccuracies below. For a while now LLVM has started rejecting aliases referring to things other than definitions[1]. This unfortunately breaks GHC's LLVM code generator which referes to most symbols through aliases. This is done in two situations, 1. As place-holders for external symbols. As the code generator does not

Hi All, The GHC developers would like to add support to llvm to enable the order that code and data are laid out in, in the resulting assembly code produced by llvm to be defined by the user. The reason we would like to have this feature is explained in the blog post on GHC's use of llvm here: http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html, specifically under the title,

Tim Northover wrote: > That shouldn't be happening. The "armv6" ought to imply ARM mode. What > Thumb instructions are you seeing, and do you have a .ll file that > reproduces the issue with standard tools or is it just the way GHC is > driving LLVM? Sorry false alarm. I was a looking an object file produced by GCC compiling a C file, not an object file produced by GHC

Somehow this cover letter was dropped from my symbol offsets patch set: 1. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073200.html 2. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073201.html Original message ----------------- About a year ago a proposal suggesting symbol offsets was brought to this list[1]. This proposal goes hand-in-hand with the prefix data proposal[2]

I found a fix! The first hunk of https://reviews.llvm.org/D17533 (lib/CodeGen/TargetFrameLoweringImpl.cpp) on top of 3.8.1 does the trick. Does llvm do patch releases of old versions? Davide Italiano <davide at freebsd.org> writes: > On Fri, Oct 21, 2016 at 6:19 AM, Shea Levy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> I'm hitting

On Tue, 8 Jun 2010 11:42:41 +0100, David Terei <davidterei at gmail.com> wrote: > Hi All, > > The GHC developers would like to add support to llvm to enable the > order that code and data are laid out in, in the resulting assembly > code produced by llvm to be defined by the user. The reason we would > like to have this feature is explained in the blog post on GHC's

Someone privately asked me to explain this example, so here goes ... > There are simpler examples of this kind for C++, because placement > new can change the dynamic type of the object (I actually haven't > looked to see if they changed this in 2012, but it was definitely > legal in C++98): > > #include <new> > struct Foo { long i; }; > struct Bar { void *p; };

On Feb 15, 2012, at 12:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 14, 2012, at 10:30 AM, David Terei wrote: > >> Hmm writing a blog post about TNTC is beyond the time I have right now. > > Sure, understandable. I'm surprised someone else hasn't already :) > >> Here is some high level documentation of the layout of Heap objects

Hi, I work on DDC, the compiler of a research Haskell dialect, Disciple (disciple.ouroborus.net (http://disciple.ouroborus.net)). We are looking to make use of LLVM's type-based alias analysis metadata to encode non-aliasing information between variables. We have found that the tbaa structure is somewhat limited in its expressivity. In particular we couldn't encode intransitive

Let me point out that projects using standard toolchain (e.g. binutils) can already reorder code and data pretty much arbitrary using sections and linker scripts. I think it's still attractive to have reordering in LLVM to be independent from external toolchain. This will allow reordering in JIT and other interesting things. I agree with John that special global with ordered list looks like

On Jun 8, 2010, at 3:42 AM, David Terei wrote: > The GHC developers would like to add support to llvm to enable the > order that code and data are laid out in, in the resulting assembly > code produced by llvm to be defined by the user. The reason we would > like to have this feature is explained in the blog post on GHC's use > of llvm here:

Hi Yiannis, As has been said GHC had this problem (I'm the author of GHC's LLVM backend). GHC uses 4 pinned registers on x86-32 and 16 on x86-64. The solution is to use a custom calling convention. I would argue that this is a better solution then having the registers completely reserved as in the middle of a function llvm can spill those registers to free them up for temporary use. Also,

On Mon, Mar 11, 2013 at 4:56 PM, Manman Ren <mren at apple.com> wrote: > > On Mar 11, 2013, at 4:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > >> On Mon, Mar 11, 2013 at 3:45 PM, Manman Ren <mren at apple.com> wrote: >>> >>> On Mar 11, 2013, at 2:37 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >>> >>>> On

On Feb 14, 2012, at 10:30 AM, David Terei wrote: > Hmm writing a blog post about TNTC is beyond the time I have right now. Sure, understandable. I'm surprised someone else hasn't already :) > Here is some high level documentation of the layout of Heap objects in GHC: > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables > > With