similar to: LLVM libraries and custom assertions.

Hi all, I made some progress on implementing Hal's proposal [1] for implementing OpenMP support in LLVM. The patch I've attached just barely compiles, but I'd like to get some input on the design early on to prevent grief later. I'd especially like some input on the following points: * Not dropping any metadata I think it is better to have an analysis pass that provides a

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

Hi all, I made some progress on implementing Hal's proposal [1] for implementing OpenMP support in LLVM. The patch I've attached just barely compiles, but I'd like to get some input on the design early on to prevent trouble later. I'd especially like some input on the following points: * Metadata is never mutated or dropped I think it is better to have an analysis pass that

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

Hi, Here is a preliminary (monolithic) version you can comment on. This is still buggy, however, and I'll be testing for and fixing bugs over the next few days. I've used your version of the strong siv test. Thanks! -- Sanjoy Das. http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: application/octet-stream

Hi all, Our use case for LLVM requires us to parse the .eh_frame sections emitted by MCJIT (for callee-saved-register spill slots, amongst other things). Does it make sense to have an in-tree parser for .eh_frame, given that it will make such tasks a lot easier? -- Sanjoy

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

> On Mar 23, 2016, at 2:44 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > > Vivek Pandya > > > On Wed, Mar 23, 2016 at 10:18 PM, Quentin Colombet <qcolombet at apple.com <mailto: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

> 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 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

Hi Hal, Preston! Sorry for the delay! Got busy with some offline work. I've worked on my previous code to calculate direction and distance vectors whenever possible (strong SIV, basically). I think the current code is much clearer and would like your opinions on it. I have attached the patch and also pushed to the github repo I mentioned [1]. Thanks! [1]

Hi Félix, Sanjoy Das wrote: > Félix Cloutier via llvm-dev wrote: > > Assuming that this is a bug, what are the next steps? > > Looks like you already have a very small test case -- have you tried > sticking it in a debugger to see why SCCP thinks removing the call is > okay? > > Alternatively, file a bug at llvm.org/bugs and someone will get to it. The third

Is copy.0 semantically equivalent to copy.1 in the following example? define void @copy.0(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst) { entry: %val = load i8 addrspace(1)* addrspace(1)* %src store i8 addrspace(1)* %val, i8 addrspace(1)* addrspace(1)* %dst ret void } define void @copy.1(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst)

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 @foo(i32* %x) > } > > ==> > > void @foo(i32* %ptr) available_externally { > } > void bar() { >

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 with LLVM's register allocator. I've CC'ed some people who can give you some more detailed information. -- Sanjoy On Tue, Feb 9, 2016 at 9:17 PM, vivek pandya via llvm-dev

Gents, I spent some time reading over Sanjoy's patch for LoopDependenceAnalysis. Unfortunately, an early version of these notes escaped; this is the complete review. First off, I agree with his choice to implement the SIV tests. For scientific Fortran, the SIV (and the simpler ZIV) tests cover about 85% of the cases in practice. For C and C++, I expect the percentage will be much higher.

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 Thu, Jan 29, 2015 at 10:01 PM, Matthias Braun <matze at braunis.de> wrote: > But > (Poison > INT_MAX) <=> poison > contradicts > (X > INT_MAX) <=> false > > and I don't think you want to abandon the second rule just because x might be poison. Maybe we could define poison in such a way that it is safe to pretend it "is" false, as per our

*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 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