similar to: [LLVMdev] Fixing segmented stacks

On Oct 18, 2011, at 2:02 PM, Sanjoy Das wrote: > This about fixing the issue with having a the BB ending with a > non-terminating instruction when compiling with segmented stacks. I'm > not sure if having an isel pseudo instruction which is lowered into a > RET and then a MOV would work better. > LLVMTargetMachine::addCommonCodeGenPasses adds the > ExpandISelPseudosPass

> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. This is exactly what I was missing. Thanks a ton! :) -- Sanjoy Das http://playingwithpointers.com

On Oct 18, 2011, at 2:33 PM, Sanjoy Das wrote: >> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. > > This is exactly what I was missing. Thanks a ton! :) We have three pseudo expansion passes: 1. ExpandISelPseudos.cpp - For instructions that may need to create basic blocks, like CMOV and atomics. 2. ExpandPostRAPseudos.cpp - For instructions used to trick the

I am creating an ExecutionEngine using the LLVMCreateExecutionEngineForModule function from the C API. I am get a set fault with the following backtrace. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000120 0x0000000107c06643 in llvm::LLVMTargetMachine::addCommonCodeGenPasses () (gdb) bt #0 0x0000000107c06643 in

On Oct 18, 2011, at 2:46 PM, Jakob Stoklund Olesen wrote: > > On Oct 18, 2011, at 2:33 PM, Sanjoy Das wrote: > >>> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. >> >> This is exactly what I was missing. Thanks a ton! :) > > We have three pseudo expansion passes: > > 1. ExpandISelPseudos.cpp - For instructions that may need to

On Feb 24, 2011, at 8:14 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: > >>> class CodeGenOpt { >>> ... >>> public >>> getOptLevel() ...; >>> getFPLevel() ...; >>> getMemLevel() ...; >>> }; >>> >>> Does this sound reasonable? >> >> I don't think that this is

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

On Sun, Feb 22, 2009 at 3:25 PM, Wesley J. Landaker <wjl at icecavern.net> wrote: > * Has anyone else out there targeted (or tried to target) a stack machine > before? Was it successfull? What problems did you have? Haven't done that, and I don't think there are any existing backends like this. It should be feasible, though; the backend code is pretty flexible. > * What

Hi llvm-dev! I have attached the current state of my GSoC work in patches [1] for review; this currently allows LLVM to correctly handle functions running out of stack space and variable sized stack objects. Firstly, since I think it is better to get things merged in small chunks, I'd like to have some specific feedback on where my work stands in terms of mergeability. Secondly, I had been

On May 18, 2010, at 8:23 AM, Daniel Dunbar wrote: > You mention some potential issues on ARM, should we sort those out > before we enable it in Clang? It's somewhat more convenient to have > things be consistent. Sure, I'll be testing some ARM code today. There is also Evan's new REG_SEQUENCE instruction to verify. > I propose that at some point you just replace the old

Hi! > According to the patch you send, the pass is not doing anything: > > +bool StackSegmenter::runOnMachineFunction(MachineFunction &MF) { > + return false; > +} > + It is, in the next patch. diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp index 5ffb8f2..cc2ca87 100644 --- a/lib/CodeGen/StackSegmenter.cpp +++ b/lib/CodeGen/StackSegmenter.cpp

Chris Lattner <clattner at apple.com> writes: >> class CodeGenOpt { >> ... >> public >> getOptLevel() ...; >> getFPLevel() ...; >> getMemLevel() ...; >> }; >> >> Does this sound reasonable? > > I don't think that this is the right way to go. Higher level > decisions like that should affect your choice of passes to

Hi! The first patch fixes the problem of a MOV after a RET by emitting a fake instruction (as suggested by Duncan), which is lowered in MCInstLower. The second patch fixes a bug reported by -verify-machineinstrs. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name:

On 10/23/2011 03:24 AM, Sanjoy Das wrote: > Hi! > > The first patch fixes the problem of a MOV after a RET by emitting a > fake instruction (as suggested by Duncan), which is lowered in > MCInstLower. > > The second patch fixes a bug reported by -verify-machineinstrs. Do you want to add -verify-machineinstrs to the test? Your patch looks good to me. I will commit it tomorrow

Hi all, I need to add thread-switching support to Unladen Swallow's JIT, and LLVM's safe point support looks like a good way to get code into all the right places. However, http://llvm.org/docs/GarbageCollection.html#collector-algos points out that there's no way to emit code at safe points yet, and there are no loop safe points at all. So I'll be trying to implement them. Is

On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > New patch taking Eli's comments into account. Comments inline. If you have commit access, I'd fire away. If not, I can. diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h index 07ca070..afff96e 100644 --- include/llvm/MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h

Hi All! This is the third iteration of my GSoC proposal, which I'm mailing here for feedback. I've already posted the proposal on Melange. The proposal is in two parts. The first, which answers the questions on application template mentioned on Melange is here [1]. I've pasted the most relevant part here: ''' Implement segmented stacks inside LLVM. Once this is

On May 17, 2011, at 2:10 PM, Justin Holewinski wrote: > I plan on eventually implementing both and seeing which works best for different types of input. > > If virtual registers are used, how do you disable final register allocation in the back-end? If post-RA passes have trouble with virtual registers, you probably need to implement your own addCommonCodeGenPasses() method.

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