similar to: [LLVMdev] Call Stacks

I sent a long message yesterday describing a problem I thought had to do with the JIT stubs. After further investigating, the problem seems to be in the code generation. The following basic block seems to have an error in it's code generation: __exp.exit: ; preds = %codeRepl258, %__exp_bb_bb.exit phi double [ 1.000000e+00, %codeRepl258 ], [ %.reload.reload.i,

I'm having an issue with the CodeExtractor. When I try to extract the lone basic block from the following function, I get an assertion error. define i32 @test(i32 %x) { %tmp = call i32 @test3( i32 %x ) ; <i32> [#uses=1] ret i32 %tmp } The assertion error is: lli: Dominators.cpp:71: void llvm::DominatorTree::splitBlock(llvm::BasicBlock*): Assertion

We are seeing some behavior we don't understand. Some of our functions are not showing up in the Call Graph because their calls contain bitcasts. The Call Graph then considers them to be external nodes. The calls look as follows: %tmp35 = call i32 (...)* bitcast (i32 (i32, i8*, i32*)* @convert to i32 (...)*)( i32 %tmp33, i8* %tmp34, i8* %tmp30 ) ; <i32> [#uses=1] After looking

As the LLVM build does not create dll's on Windows, two problems arises: 1. Static linking creates big executables. 2. Link time is long. We can create dll's on MinGW using a feature of binutils that mimics .so files on GNU/Linux. The process is very simple. On a MSYS or Cygwin shell (make sure MinGW binaries are on the path before Cygwin's). Read all message before rolling up

> "./ices: error while loading shared libraries: libshout.so.1: cannot > open shared object file: No such file or directory" >>Is libshout installed? What I know I haven't installed it, is there a debian package of it so I can install or reinstall it mayne? >>Did you run ldconfig? When I do a ldconfig I get this back in return " ldconfig:

Commit-ID: c562319cdba0102c3a8a8298ba94e645418193d5 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=c562319cdba0102c3a8a8298ba94e645418193d5 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Wed, 29 Apr 2020 22:28:10 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 25 Jul 2020 17:33:29 +0100 [klibc] Kbuild: Add a

Commit-ID: 9d8d648e604026b32cad00a84ed6c29cbd157641 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=9d8d648e604026b32cad00a84ed6c29cbd157641 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sat, 29 Feb 2020 00:03:20 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 29 Feb 2020 00:11:26 +0000 [klibc] Kbuild: Tell gas we

Commit-ID: 312b3d0a38ff2e43becd47cf1f4a930bc0c4b8e6 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=312b3d0a38ff2e43becd47cf1f4a930bc0c4b8e6 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Wed, 29 Apr 2020 22:24:33 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 25 Jul 2020 17:33:29 +0100 Revert "[klibc] Kbuild: Tell

Commit-ID: 27ad55131385821dfe85b0320f4d6ba8861ab7e5 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=27ad55131385821dfe85b0320f4d6ba8861ab7e5 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Wed, 29 Apr 2020 22:56:59 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 25 Jul 2020 17:33:29 +0100 [klibc] arch: Explicitly disable

Dear Sirs: I wish to report my experience with the package. I have compiled and used Samba 2.0.7pre 2, pre3, and pre4. I have not had any trouble connecting to Samba's shares (from an NT client), but I would like to report a problem with SMBFS and SMBMOUNT. NT4, SP5 shares mounted into the filespace of the Linux box can disconnect over time with two possible outcomes. The activity is

Chris Lattner wrote: > On Wed, 11 Jan 2006, Ben Chambers wrote: > >> I was wondering what the current state of this (explicitly managed >> stack frames) >> is. Is it being worked on? If not, how hard do you think it would >> be for me to >> add it? > > > I'm not sure what you mean. It depends on correct tail calls, but no > other

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>

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

On Thu, Jun 23, 2011 at 03:21:58PM -0400, Brian Hurt wrote: > Segmented stacks are exciting to me, but only if the stacklets can be > freed. Here's why: if segmented stacks allow for "infinite" stacks, tail > call optimization becomes a lot less important in functional languages- > still useful, but not live or die. We discussed this on IRC a while ago. IMHO it is

Hi all! Attached a three part series which implements the very first bits of my GSoC proposal (full proposal is here http://pastebin.com/e9JMZNCE), for some preliminary review. -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adds-relevant-command-line-options.patch Type: text/x-diff Size: 2021 bytes Desc: not

Hi Sanjoy, > I've been working on implementing support for segmented stacks in LLVM > (towards GSoC '11). Currently I'm working on adding intrinsics for > coroutines. The problem is this: > > Till now I had been depending on libgcc for runtime support (and was > being 100% libgcc compatible in the process). However, since all the > stack allocation routines in

Hi Sanjoy, The patch generally looks fine except for this part: diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp new file mode 100644 index 0000000..5ffb8f2 --- /dev/null +++ b/lib/CodeGen/StackSegmenter.cpp @@ -0,0 +1,48 @@ +//===-- StackSegmenter.h - Prolog/Epilog code insertion -------*- C++ -* --===// The comment is obviously incorrect. diff --git

On 11-06-02 07:47 PM, Peter Lawrence wrote: > Guys, > regarding alloca. > > not only are exceptions a problem here, but just plain old "longjmp". Yes, On IRC Sanjoy pointed out that it should be possible to handle this by changing longjmp. I am not sure it can be done in general. The alloca might have been called a dynamic number of times for example. In fact, now that I

On Thu, 23 Jun 2011, Joerg Sonnenberger wrote: > On Thu, Jun 23, 2011 at 03:21:58PM -0400, Brian Hurt wrote: >> Segmented stacks are exciting to me, but only if the stacklets can be >> freed. Here's why: if segmented stacks allow for "infinite" stacks, tail >> call optimization becomes a lot less important in functional languages- >> still useful, but not

Sorry for the delay in responding. On Mon, 13 Jun 2011, Rafael Avila de Espindola wrote: > On 11-06-02 07:47 PM, Peter Lawrence wrote: >> Guys, >> regarding alloca. >> >> not only are exceptions a problem here, but just plain old "longjmp". > > Yes, > On IRC Sanjoy pointed out that it should be possible to handle this by > changing longjmp. I am