similar to: [LLVMdev] Dynamic Optimization Infrastructure

Hi everyone. I'm mainly build the debug versions of lli and opt which are huge and take up to 10 seconds to build. It seems there is no option in configure to allow dynamic linking. Before I try to add it myself, is there a reason why it's not done? On Fri, Oct 3, 2008 at 6:14 PM, Yale Zhang <yzhang1985 at gmail.com> wrote: > Does anyone know if LLVM will soon have a dynamic

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

Hi, > I'm parallelizing loops to be called by pthread. The thread body that I pass > to pthread_create looks like > > define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) > parent_frame is pointer to shared variables in original function > > 0x00007f0de11c41f0: mov (%r10),%rax > 0x00007f0de11c41f3: cmpl $0x63,(%rax) > 0x00007f0de11c41f6:

Attached patches change how dragonegg lowers trampolines (for compatibility with Go). -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-the-trampolines-for-Go.patch Type: text/x-diff Size: 5108 bytes Desc: not available URL:

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A)

On Tue, 2020-02-25 at 13:36 -0800, Kees Cook wrote: > On Thu, Feb 06, 2020 at 04:38:34PM +0100, Christophe Leroy wrote: [...] > > Indeed, the stack is rwx, which is unexpected. And it is the case for all > > klibc tools. > > > > How can we fix that ? > > klibc uses trampolines for its setjmp implementation. I ran into this > years ago when eradicating

On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote: > On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote: > > On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote: > > > In Debian testing the initrd triggers the warning. > > > > > > [ 34.529809] process '/usr/bin/fstype' started with executable stack > > > >

Eli Friedman wrote: > Also, for lack of an intrinsic, there's a relatively easy workaround: > you can declare a global containing the correct size, then link in a > small target-specific .bc with the definition right before code > generation. So why can't LLVM provide that global? I don't care whether it's a global, intrinsic, or whatever. If I have to provide

Hi, I want to implement nested functions using llvm and I can't find much info on how to do this. Do I have to manually create frames, link them via static links and pass as an additional function argument or does llvm give some helper functions? Thanks in advance, Michal.

Hi Hayden, Dave's answer covers this pretty well. Neither Orc nor MCJIT currently reason about replacing function bodies. They may let you add duplicate definitions, but how they'll behave if you do that isn't specified in their contracts. They definitely won't replace old definitions unless you provide a custom memory manager that's rigged to lay new definitions down on top

Dear all, I'm trying to use LLVM 2.7 (running on a x86-32 platform) as cross compiler to build ADA programs that will run on a different target platform (PowerPc). The LLVM documentation states that: "The only platform for which the Ada front-end is known to build is 32 bit intel x86 running linux. It is unlikely to build for other systems without some work." and also: "The

On 04 Jan 2011, at 08:30, Jakob Stoklund Olesen wrote: > I noticed that we generate code like this for i386 PIC: > > calll L0$pb > L0$pb: > popl %eax > movl %eax, -24(%ebp) ## 4-byte Spill > > I worry that this defeats the return address prediction for returns > in the function because calls and returns no longer are matched. According to benchmarks by

On 10/10/2017 9:00 PM, Rui Ueyama wrote: > I'm not sure if I understand correctly. If my understanding is > correct, you are saying that GHC can link either .o or .so at runtime, > which sounds a bit odd because .o is not designed for dynamic linking. > Am I missing something? Yes, GHC runtime linker *does* link .o files not only doing all necessary relocations but also

Hi Nick, There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. The options that are shared between Darwin/GnuLD are :- a) -o b) -L c)

Hi Sanjoy, > Attached patches change how dragonegg lowers trampolines (for > compatibility with Go). I think the right approach is to add an llvm.adjust.trampoline intrinsic to LLVM (and change llvm.init.trampoline to not return a result). Then the dragonegg trampoline code will become trivial, and the Go problem will just Go away :) In fact this was how I first did it: two intrinsics,

Taking the address of a function inhibits optimisations for that function. Essentially any ABI changes are unavailable if we can't adjust the call site to match. The case of interest here is when a given function is called directly and indirectly, and we don't want the latter to impose a cost on the former. One approach to avoid the ABI constraint cost is to extract/outline the body of an

This reverts commit 9d8d648e604026b32cad00a84ed6c29cbd157641, which broke signal handing on some architectures. On m68k and parisc, signal return depends on a trampoline that the kernel writes on the stack. On alpha, s390, and sparc (32-bit), we can avoid this by providing our own function as sa_restorer, but we currently don't. Signed-off-by: Ben Hutchings <ben at decadent.org.uk>

Hi Sanjoy, >> (1) Replacing function bodies at the same address is impossible if the >> function is already on the stack: You'd be replacing a definition that >> you're later going to return through. > > If the function you wish to replace is active on the stack, you can > replace the return PC that was going to return into that active frame > with a PC

On 9/18/2013 4:31 PM, Nick Kledzik wrote: > On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > >> Hi Nick, >> >> There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. >> >> As the first step, I am thinking

On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. > > As the first step, I am thinking of consolidating the common options shared across all the Unix