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

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

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

On 29 June 2012 17:46, Karel Gardas <karel.gardas at centrum.cz> wrote: > Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on > ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The > code in GHC is properly #ifdefed, so if there is no VFP available on pre > ARMv6, then it's not used. ie. GHC STG floating points regs are then >

Reid Kleckner <rnk at google.com> writes: > On Tue, Jun 3, 2014 at 1:29 PM, Rafael Espíndola <rafael.espindola at gmail.com >> wrote: > >> > 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

> This is starting to look very similar to how ARM constant islands work, without the extra ugliness from how small the ARM immediate displacements are. > > -Jim Would there be any reason that this couldn't be seen as an opportunity to move the constant islands pass out of the ARM backend and make the target-independent constant pools (which ARM bypasses completely) more generic?