search for: bisectors

...ns, so that 1) each polygon contains exactly one point 2) the polygon defines the area for which this specific point is closer than any other point. It's a bit like a map of areas "influenced" by that point, and it's obviously a matter of intersecting the perpendicular bisectors between adjacent points. I believe this type of map has a name, but I can't remember how it's called. Is there a function somewhere in a R package that may do this? Thanks for your help Pascal

So... looking at OptBisect, I have a few thoughts: 1) what's the purpose of the virtual interface/OptPassGate? I'm guessing maybe that worked around the circular referencing in these APIs? hmm, no, I suppose that wouldn't work/be relevant here. 2) Why is OptBisector a ManagedStatic? That seems pretty antithetical to the role of LLVMContext. When/why would a user be bisecting over

Hi all, Just wanted to see if anyone could answer this dumb question I had. I wrote a bisector for the inliner based on caller/callee at Inliner.cpp, but I am getting conflicting results. Does anyone know if the inlining order is deterministic? Regards, Kevin Intel WOS -------------- next part -------------- An HTML attachment was scrubbed... URL:

& now looking back at the patch-in-progress, I see it allows setting the OptBisector/OptPassGate as suggested in (2). If that becomes the /only/ option (ie: LLVMContext has no default OptPassGate) then the virtual interface could be kept down in IR (though it's still a bit questionable to have those Analysis types (Loop, Region, CallGraphSCC) even declared in IR). Then the implementation

Andrew, I would not make the caller pass the description of the IR unit. That is because it would result in the description generated every time even if OptBisect is disabled. Description generation is not very chip. Thinking on the OptBisect extension, I believe passing the units are the right choice because OptPassGates may use them to make pass skipping decisions. -Yevgeny Rouban

On 03/30/2018 12:05 AM, David Blaikie via llvm-dev wrote: > & now looking back at the patch-in-progress, I see it allows setting the OptBisector/OptPassGate as suggested in (2). Well, the patch currently discussed does not attempt to solve the passgate object management issue. It is left for the discretion of passgate object provider. > > If that becomes the /only/ option (ie:

On Mon, Apr 2, 2018 at 11:32 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 03/30/2018 12:05 AM, David Blaikie via llvm-dev wrote: > > & now looking back at the patch-in-progress, I see it allows setting > the OptBisector/OptPassGate as suggested in (2). > Well, the patch currently discussed does not attempt to solve the > passgate object

> Pass Manager (PassManager.h) itself, does not - it's only templates, none of it depends on Region, Loop, etc. Well, true but the problem happens when you try to instantiate the thing. And for generic features like opt-bisection, ir-print-after-all etc that want:   - to have a say before/on/after every execution of every pass   - have a shared implementation of the main logic you have

On Tue, Apr 3, 2018 at 8:50 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > Pass Manager (PassManager.h) itself, does not - it's only templates, > none of it depends on Region, Loop, etc. > Well, true but the problem happens when you try to instantiate the thing. > And for generic features like opt-bisection, ir-print-after-all etc that > want: > - to

Here are four small patches. First, I enabled all the warnings, then I fixed the newly exposed offenses, then I put the warning-enabling patch at the end, for the sake of future bisectors: [1/4] ocaml/guestfs_c.c avoid signed/unsigned-comparison warning [2/4] ocaml/guestfs_c.c: avoid warning about initialization discarding "const" [3/4] ocaml/guestfs_c.c: avoid warning about missing prototypes [4/4] build: enable gcc warnings in capitests/ and ocaml/ >From 1accb67720...

David, we definitely need to address this issue and I did not forget about it. I'm still fleshing out a proposal on a generic solution for "pass execution control points", which was inspired by the new pass manager needs but then it appears we can largerly reuse the implementation for both managers. Since the implementation should be based on a special Analysis, it definitely

Ping on this - any chance we can look at fixing the OptBisect layering here/now? Could we move the implementation into Analysis & require users to set it, rather than having it as a default value in IR? On Tue, Apr 3, 2018 at 9:25 AM David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Apr 3, 2018 at 8:50 AM Fedor Sergeev <fedor.sergeev at azul.com> > wrote: >

I've worked on a compiler with a counter, but for individual optimisations, not just passes. It was incredibly useful! In the llvm world, it would let you bisect exactly which instcombine, dagcombine, or whatever causes an issue. I support the addition of a pass counter if it helps bisecting, but just wanted to point out that this can be as fine grained as the community is willing to accept.

I agree that the more fine grained this becomes the more useful it can be. I’ve updated my prototype to use a single number approach. I’m going to clean this up and post a review in the next day or two. -Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pete Cooper via llvm-dev Sent: Friday, March 25, 2016 10:22 PM To: Matthias Braun <matze at braunis.de> Cc:

Hi Greg, Thanks for your input! I’d love to see this evolve into something that would let us track problems to individual IR changes. My thinking is that starting with passes gives us something that will get us maybe 70% of the functionality in one easy step, then individual passes can be instrumented as anyone has time or need to get us the rest of the way there. Your max_opt option sounds

Ok I cleaned it up and added some explaining comments. It's in llvm/utils/abtest now. - Mathias > On Mar 25, 2016, at 4:40 PM, Michael Gottesman <mgottesman at apple.com> wrote: > > >> On Mar 25, 2016, at 4:37 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote: >> >> And as we are on the topic of bisecting/diagnosing