similar to: [LLVMdev] [PATCH] Correct documentation

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:

Current set of patches for my work on segmented stacks. Go / dragonegg seems to work when using this code (I still haven't run any rigorous tests yet). Thanks! (Also on https://github.com/sanjoy/LLVM/tree/segmented-stacks) -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi all! Now that LLVM has support for a larger attribute set, I think it is a good idea to add one that stops LLVM from generating segmented stacked version of a function. While implementing it, I ran into an issue: Currently, with segmented stacks enabled, LLVM sets the action for DYNAMIC_STACKALLOC to Custom, and lowers it into native X86 code. However, if a function has the nosegmentedstack

No need to apologize this thread surely deserved some answers :) From my perspective this project sounds doable. I would expect the register allocation parts to be not too hard: I imagine this being just distilling a new clobber regmask after allocating a function. I would expect the challenging (or annoying) part to get a machine module pass (or a similar mechanism to influence the order in

>From the research and code I've seen - Doesn't this break regalloc down into a global and location allocation strategy? (maybe I'm remembering incorrectly) On Wed, Mar 23, 2016 at 12:04 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Mar 22, 2016, at 6:04 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>

*Vivek Pandya* On Wed, Mar 23, 2016 at 9:43 AM, C Bergström <cbergstrom at pathscale.com> wrote: > From the research and code I've seen - Doesn't this break regalloc > down into a global and location allocation strategy? (maybe I'm > remembering incorrectly) > > Yes I think you are correct. If I recall IP Reg allocation allocates some registers to varibale that

The pass manager already has support for calligraph connected region IIRC. As for the regmask part, we probably could hack something up in a week or so, but I believe this is not what Vivek had in mind. I think the main challenge of a real inter-procedural register allocator is to change all of the calling convention dynamically and more importantly convey the right information to other tools

*Vivek Pandya* On Wed, Mar 23, 2016 at 10:18 PM, Quentin Colombet <qcolombet at apple.com> wrote: > The pass manager already has support for calligraph connected region IIRC. > If I am not wrong Quentin and Mehdi Amini refers to CallGraphSCCPass.cpp > As for the regmask part, we probably could hack something up in a week or > so, but I believe this is not what Vivek had in

> On Mar 22, 2016, at 6:04 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > No need to apologize this thread surely deserved some answers :) > > From my perspective this project sounds doable. I would expect the register allocation parts to be not too hard: I imagine this being just distilling a new clobber regmask after allocating a function. I would

Apologies: didn't notice how old this thread is before replying. On Tue, Mar 22, 2016 at 5:24 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Vivek, > > [+CC Matthias, Quentin] > > Inter-procedural register allocation can be a big win, but my estimate > is that it will be challenging to complete within one summer unless > you're already familiar

On 02/26/2016 08:04 PM, Chandler Carruth wrote: > On Fri, Feb 26, 2016 at 7:59 PM Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > *From: *"Chandler Carruth" <chandlerc at google.com > <mailto:chandlerc at google.com>> > *To: *"Hal Finkel" <hfinkel at anl.gov <mailto:hfinkel at

Hi Sanjoy, Here's a version of Banerjee and Wolfe's Exact SIV test: https://sites.google.com/site/parallelizationforllvm/weak-siv-test It assumes you've already filtered out the easy cases handled by ZIV, strong SIV, etc. I'm not confident about my uses of APInt. If you have any comments, I'd love to hear them. Thanks, Preston On Thu, Apr 12, 2012 at 5:14 AM, Sanjoy Das

On Fri, Feb 26, 2016 at 7:08 PM Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > On Thu, Feb 25, 2016 at 9:59 AM, Sanjoy Das > <sanjoy at playingwithpointers.com> wrote: > > Couple of other examples: > > > > void @foo(i32* %ptr) available_externally { > > %discard = load i32, i32* %ptr > > } > > void bar() { > > call

Here's an idea for a slightly unusual framework for poison semantics: we do it in two steps -- 1. for every bit in the program, we define a second "shadow bit", is-poison. We define the semantics of LLVM IR using this is-poison relation. So, for instance, we could say if there is a bit 'b'in address 'a' such that if is-poison['b'], then "store X to

On Fri, Feb 26, 2016 at 7:59 PM Hal Finkel <hfinkel at anl.gov> wrote: > *From: *"Chandler Carruth" <chandlerc at google.com> > *To: *"Hal Finkel" <hfinkel at anl.gov> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" < > listmail at philipreames.com>, "Duncan P. N. Exon Smith" < >

Hi Sanjoy, Reading through LoopDependenceAnalysis::analyseStrongSIV(), I noticed one problem and one confusion. My confusion related to your naming of the two instructions as A and B. It's consistent all through LoopDependenceAnalysis. I'd prefer something like source and destination, so I can keep track of which is which. It didn't matter so much when you were simply proving or

On Sat, Feb 27, 2016 at 1:41 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Just as a reality check, I wrote up a demonstration where one link > order causes a SIGFPE and another doesn't (and the program is well > defined, as far as I can tell). All TUs are compiled with -O3. This is also > an instance where we don't actually speculate an inline function,

Hi llvmdev! 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 libgcc depend on TLS variables to

> On Jun 11, 2015, at 12:48 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > On Thu, Jun 11, 2015 at 12:02 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote: >> >>> On Jun 10, 2015, at 11:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >>> >>>> Base is treated as unsigned so

> On Mar 23, 2016, at 2:59 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Mar 23, 2016, at 2:44 PM, vivek pandya <vivekvpandya at gmail.com <mailto:vivekvpandya at gmail.com>> wrote: >> >> >> >> Vivek Pandya >> >> >> On Wed, Mar 23, 2016 at 10:18 PM, Quentin Colombet <qcolombet at