search for: juliacomput

Keno, Perhaps you can view the problem to be the memcpys themselves, We humans can look at the memcpys and see loads and stores but to almost all optimizer passes they aren’t what it is looking for, They instead see function calls which they mostly don’t touch, If these memcpys were inlined into plain old loads and stores The redundant loads and stores should be deleted by existing opts

...doing this, instead your new pass (that first checks to see if it is legal w.r.t. calling convention) is The place to do this, or if should convert to pure “by-reference” if legal, which also shouldn’t be done in GVN. —Peter Lawrence. > On May 17, 2017, at 8:55 AM, Keno Fischer <keno at juliacomputing.com> wrote: > > Well, mostly I want to hoist the store to the stack and transform it into a store to the heap. After that the memcpys are essentially trivially dead, so instcombine or dse will delete them for me. If the memcpys were made of individual stores instead, there'd have t...

I left a comment on https://reviews.llvm.org/D18738 earlier which I feel is related to this discussion, so I'm reproducing it here: I wonder though if what we want to express isn't some sort of "type-based dereferencability annotations". For example the semantics I care about are essentially, "if you know you have a defereferencable pointer, you can go and dereference any

...case? > > Sergei > > -----Original Message----- > From: aprantl at apple.com [mailto:aprantl at apple.com] > Sent: Monday, June 19, 2017 5:00 PM > To: Sergei Larin <slarin at codeaurora.org> > Cc: llvm-dev <llvm-dev at lists.llvm.org>; Keno Fischer <keno at juliacomputing.com> > Subject: Re: [llvm-dev] CloneFunctionInto produces invalid debug info > > - old Keno > +current Keno >> On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> In your example the instructions in the cloned function have debu...

...e this is not much help. >>> >>> Sergei >>> >>> From: aprantl at apple.com [mailto:aprantl at apple.com] >>> Sent: Thursday, June 15, 2017 5:25 PM >>> To: Sergei Larin <slarin at codeaurora.org> >>> Cc: Keno Fischer <keno at juliacomputing.com>; llvm-dev at lists.llvm.org >>> Subject: Re: [llvm-dev] CloneFunctionInto produces invalid debug info >>> >>> Can you send me a patch with instructions to reproduce? I can take a look. >>> >>> -- adrian >>>> On Jun 15, 2017, at 2...

...lt;<<< > } > > Sorry, I realize this is not much help. > > Sergei > > From: aprantl at apple.com [mailto:aprantl at apple.com] > Sent: Thursday, June 15, 2017 5:25 PM > To: Sergei Larin <slarin at codeaurora.org> > Cc: Keno Fischer <keno at juliacomputing.com>; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] CloneFunctionInto produces invalid debug info > > Can you send me a patch with instructions to reproduce? I can take a look. > > -- adrian >> On Jun 15, 2017, at 2:23 PM, Sergei Larin <slarin at codeaurora....

Can you send me a patch with instructions to reproduce? I can take a look. -- adrian > On Jun 15, 2017, at 2:23 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Yes, it does for us. My tree is couple days off the tip, and I see it there. > > Sergei > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Keno Fischer via llvm-dev > Sent:

Maybe it would illustrative to give an IR example of the case I'm interested in. Consider define void @"julia_transform_bvn_derivs_hessian!"(double* %data, double* %data2, double *%data3, double *%out) { %element11 = getelementptr inbounds double, double* %data, i32 1 %load10 = load double, double* %data %load11 = load double, double* %element11 %element21 =

There was some discussion of this on the llvm-commits list, but I wanted to raise the topic for discussion here. The background of the -commits discussion was that r296863 added the ability to sort memory access when the SLP vectorizer reached a load (the SLP vectorizer starts at a store or some other sink, and tries to go up the tree vectorizing as it goes along - if the input is in a different

Totally agree Philip! I think the main pending issue is are we allowed to have a target that doesn't go through the normal mechanisms that targets adhere to - and is basically just a ModulePass underneath. In light of how thorny this request has been perceived in the past, I'd honestly rather just make external targets work _without_ patching LLVM being a requirement, and then any