similar to: GlobalISel: Very limited pattern matching?

> On May 20, 2019, at 10:04, Quentin Colombet <qcolombet at apple.com> wrote: > > +gisel folks > > Hi Alex, > > You’re doing the right thing. > That’s a known limitation that we’ve discussed in https://reviews.llvm.org/D59227 <https://reviews.llvm.org/D59227> but we didn’t really reach a conclusion back them. > Short term, I believe you’re right, we should

Hi all, Over the past few months we’ve been doing work on the foundations for the next stages of GlobalISel development. In terms of changes from this time last year, the IR translator, the legalizer, and instruction selector have seen moderate to major changes. The most significant of these was the change to the legalizer API, allowing targets to use predicates to express legality, which gives

> On 30 Jul 2018, at 16:04, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Amara, > > Thanks for sharing the plan going forward. > > Inlined a couple of comments. > > 2018-07-30 7:01 GMT-07:00 Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: >> Hi all, >> >>

> On 2 Aug 2018, at 14:50, Quentin Colombet <quentin.colombet at gmail.com> wrote: > > Hi Daniel, > > 2018-07-31 8:40 GMT-07:00 Daniel Sanders <daniel_l_sanders at apple.com>: >> >> >> On 30 Jul 2018, at 16:04, Quentin Colombet via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> Hi Amara, >> >> Thanks for

Hi, I would like to get rid of the logic around disabling GlobalISel from the build. *** Context *** So far, GlobalISel has been this framework built up on the side for about two years. Now, we are close to a point where having it being optional impedes our ability to implement the right things. For instance, checks that would fit naturally in the MachineVerifier are directly done during the

Hi Kristof, Thanks for the measurements. > On May 24, 2017, at 6:00 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 23 May 2017, at 21:48, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Great! >> I thought I had to look at our pipeline at O0 to make sure optimized regalloc was

Hi GlobalISel interested parties, A recent bug report (https://bugs.llvm.org/show_bug.cgi?id=40968) on AArch64 exposed a problem with our modeling of intrinsic semantics when dealing with type overloaded calls. The crux of the matter is that because GlobalISel’s LowLevelTypes only carry size and vector layout information, and not any information about whether a type is integer or fp, we lose

Great! I thought I had to look at our pipeline at O0 to make sure optimized regalloc was supported (https://bugs.llvm.org/show_bug.cgi?id=33022 <https://bugs.llvm.org/show_bug.cgi?id=33022> in mind). Glad I was wrong, it saves me some time. > On May 22, 2017, at 12:51 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > >> On 22 May 2017, at 09:09, Diana Picus

Thanks Kristof. Sounds like we'll need to investigate though I'd say it is not blocking the switch. At this point I think everybody is on board to flip the switch. @Eric, how does that sound to you? Thanks, Q > Le 1 juin 2017 à 07:46, Kristof Beyls <Kristof.Beyls at arm.com> a écrit : > > >> On 31 May 2017, at 17:07, Quentin Colombet <qcolombet at

Hi all, We had some internal discussions about flipping the default for O0 and we concluded that we wanted to postpone it. *** Why Is That? *** We don’t want to send the wrong message that GlobalISel’s design is set in stone and ready for broader adoption. In particular, 1. The APIs are still evolving and can still possibly change significantly 2. The TableGen backend to reuse the existing SD

Hi everyone, This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from correctness and reducing the fallback rate to SelectionDAG at -O0, we’re now starting to think about using GlobalISel with optimizations enabled. There are obviously many parts to this story as optimizations

Hi all, I added a buildbot [1] running the test-suite with -O0 -global-isel. It runs into the same 2 timeouts that I reported previously on this thread (paq8p and scimark2). It would be nice to make it green before flipping the switch. At the moment, it lives in an internal buildmaster that I've setup for this purpose. If we fix it and it proves to be stable for a week or two, I'll move

I don’t know of any further issues preventing us flipping the switch. At this point, I’d aim to flip the switch shortly after the creation of the 6.0.0 release branch, so that GlobalISel can harden a bit more enabled-by-default on trunk before it goes into an LLVM release (presumably 7.0.0 then). Thanks, Kristof > On 11 Dec 2017, at 17:08, Amara Emerson <aemerson at apple.com> wrote:

On 4 January 2018 at 17:10, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. Thanks for the insight Daniel, much appreciated. >> * MipsCCState: adds bool

Hi, I've been studying the global instruction selector introduced recently. One of the properties of global instruction selectors is that they select instructions across basic blocks such that they can get more information in order to choose optimal patterns. However, the current global isel implementation still iterates over BBs within functions, which is same as the original SelectionDAG

Hi all, Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. As explained during the last developer meeting, we are aiming at

Hi Quentin, My only remaining concern is around ABI compatibility. The following commit seems to indicate that in the previous round of evaluation, we didn’t find an existing ABI compatibility issue: http://llvm.org/viewvc/llvm-project?view=revision&revision=311388. I haven’t looked into the details of this issue - so maybe I’m worried over nothing? I’m wondering if since then on your side

> On Nov 10, 2018, at 03:28, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Thank you for the detailed reply! There's a lot to digest :) Let me try to address most of it. > > > [snip] >>> I also think you should have 'ins' and 'outs' separately; after all, a predicate may have to do a combined check on two matched registers / operands,

On 12 June 2017 at 18:54, Diana Picus <diana.picus at linaro.org> wrote: > Hi all, > > I added a buildbot [1] running the test-suite with -O0 -global-isel. It > runs into the same 2 timeouts that I reported previously on this thread > (paq8p and scimark2). It would be nice to make it green before flipping the > switch. > > I did some more investigations on a machine

This question came about through reviewing work from Leslie Zhai on GlobalISel support for RISC-V, which also motivated me to revisit code which I've always felt was a bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT,