similar to: [LLVMdev] [PATCH] Symbol offsets

+the people I hashed this out with so many months ago I think it's a reasonable proposal, but obviously I floated it. :) Let's try to get a second opinion. Again, it's a syntax something like: define void @foo() prefix [i8* x 2] { i8* @a, i8* @b } prologue [i8 x 4] c"\xde\xad\xbe\xef" { ret void } On Thu, Aug 21, 2014 at 1:58 PM, Ben Gamari <bgamari.foss at

Rafael Espíndola <rafael.espindola at gmail.com> writes: > Now that aliases can have any expressions, can't you use something like > > @data = private global [2 x i32] [i32 42, i32 43] > @symbol = alias getelementptr ([2 x i32]* @data, i32 0, i32 1) > > This produces > > .Ldata: > .long 42 # 0x2a > .long 43

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

Rafael Espíndola <rafael.espindola at gmail.com> writes: >> I suspected this was the case. Is a rework of prefix support likely to >> make it in for 3.5? >> > > Unlikely. It has branched already and I don't know of anyone working on it. > Fair enough. If there is consensus around a reasonably concrete proposal I would be happy to put together a patch

Rafael Espíndola <rafael.espindola at gmail.com> writes: > On 25 May 2014 21:29, Ben Gamari <bgamari.foss at gmail.com> wrote: >> >> For a while now LLVM has started rejecting aliases referring to things >> other than definitions[1]. > > We started checking for it. Aliases are just another label in an > object file. The linker itself doesn't know they

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

Rafael Espíndola <rafael.espindola at gmail.com> writes: > On 25 May 2014 21:29, Ben Gamari <bgamari.foss at gmail.com> wrote: >> Sure. I think the only reason our use of aliases worked previously was >> that the optimizer elided them long before they could make it into an >> object file. > > If that is the case, you should be able to just directly replace

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:

Hello everyone, On behalf of GHC hackers, I would like to discuss the possibility of having a proper implementation of the tables-next-to-code optimisation in LLVM. Currently, the object code produced by all three GHC backends follows the convention that the table with the metadata of a closure is located immediately before the code of the closure. This makes it possible to get to both the code

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

Hi Tim, Thank you for your reply. Actually, I already played with various target triples including what sys::getProcessTriple() returns when I tried to compile it on a Raspberry Pi 3 device. Yes, changing the triple to armv7-unknown-linux-gnueabi changes the emitted return instruction to 'bx lr'. But this is not the issue. Let me describe it based on an example I prepared to demonstrate

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

Hmm writing a blog post about TNTC is beyond the time I have right now. 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 TNTC enabled we generate code for closures of this form: .text .align 8 .long Main_main1_srt-(Main_main1_info)+0 .long 0 .quad 4294967299 .quad 0

> The semantics around inlining alone are problematic enough to warrant serious hesitation. There are nicer ways to embed CPS call/return into LLVM; I just figured that there would not be much support for adding a new terminator because it would change a lot of code. Ideally we would have a block terminator like: cps call ghccc @bar (.. args ..) returnsto label %retpt Where the

Hi Karel, >>> > const unsigned* >>> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >>> const { >>> > + bool ghcCall = false; >>> > + >>> > + if (MF) { >>> > + const Function *F = MF->getFunction(); >>> > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false);

Hi Duncan, On 10/14/11 03:56 PM, Duncan Sands wrote: > Hi Karel, > >> > const unsigned* >> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >> const { >> > + bool ghcCall = false; >> > + >> > + if (MF) { >> > + const Function *F = MF->getFunction(); >> > + ghcCall = (F ? F->getCallingConv() ==

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 >

On Feb 13, 2012, at 6:49 AM, Sergiu Ivanov wrote: > On behalf of GHC hackers, I would like to discuss the possibility of > having a proper implementation of the tables-next-to-code optimisation > in LLVM. It would be great to have this. However, the design will be tricky. Is there anything that spells out how the TNTC optimization works at the actual machine instruction level? It

Hi Renato, On 06/25/12 12:13 AM, Renato Golin wrote: > Hi Karel, > > I understand this patch has already been merged (to 3.0), so don't > take my question as stopping the merge to head, I'm just making sure I > got it right... The rest looks correct. > > + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, > + CCIfType<[f64], CCAssignToReg<[D8, D9,

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,