similar to: GlobalISel: Ambiguous intrinsic semantics problem

Matt: that’s fair. We’re generally apprehensive of option 2 as well. Eli: Yes, currently we believe that aarch64.neon.addp is the only arm64 one affected, but we don’t know how prevalent this is on other targets. Splitting it is certainly possible combined with the autoupgrader. If disambiguating the intrinsics is the preferred solution, then I think we should also have the langref also specify

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 May 5, 2020, at 2:45 PM, Ties Stuij <Ties.Stuij at arm.com> wrote: > > Quentin: Thanks for the info. I was under the impression that the LLVM community at large would prefer to extend the IR type to a bfloat MVT type. I've made a number of patches to implement this up to a point for AArch64. I can post those on Phab and start a thread to sample opinions. Sounds good to

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

I’ve put up a patch here: https://reviews.llvm.org/D79769 <https://reviews.llvm.org/D79769> that adds a unified pipeline that targets can opt-into. It has some similarities with forcing fallbacks, but uses a different mechanism to do so to preserve the abort behavior. It therefore requires that every GISel pass needs to explicitly check whether the GISel selector is being requested rather

Hi all. I’m trying to get GlobalISel to work better with LTO. At the moment if you enable it via -fglobal-isel, it only adds the -mllvm -global-isel and related options to the cc1 invocation. With LTO, that doesn’t work as we need to encode codegen options into the bitcode, usually via function attributes. Does anyone have any ideas on how to achieve this? The only way I can see it working is if

Hi Amara, My reasons for preferring the switch to happen after the release branch is based on the following observations: * As far as I can see, the projects and products following top-of-trunk tend to test much more extensively than the testing that happens for llvm.org<http://llvm.org> releases. I expect that the llvm.org<http://llvm.org> release testing won’t find potential

On 18 Dec 2017, at 15:11, Amara Emerson <aemerson at apple.com<mailto:aemerson at apple.com>> wrote: On Dec 18, 2017, at 12:37 PM, Kristof Beyls <Kristof.Beyls at arm.com<mailto:Kristof.Beyls at arm.com>> wrote: Hi Amara, My reasons for preferring the switch to happen after the release branch is based on the following observations: * As far as I can see, the

FYI all: the patch to enable it is available to review here: https://reviews.llvm.org/D41362 Thanks, Amara > On Dec 18, 2017, at 5:44 PM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Ok. We’ll look at what we can do to further stress test it in the next two months, additional suggestions from the community is welcome. Patch should be incoming to enable it

Thanks all. Amara, could you take a look? > On Nov 20, 2017, at 3:06 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > I’ve raised: > https://bugs.llvm.org/show_bug.cgi?id=35359 <https://bugs.llvm.org/show_bug.cgi?id=35359> > https://bugs.llvm.org/show_bug.cgi?id=35360 <https://bugs.llvm.org/show_bug.cgi?id=35360> >

Unless there are still open issues with your patch, or our internal bots point to problems, I think time has come to flip the switch. Thanks Gerolf > On Dec 18, 2017, at 11:14 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > FYI all: the patch to enable it is available to review here: https://reviews.llvm.org/D41362 <https://reviews.llvm.org/D41362>

Hi all, For GlobalISel, we’re exploring options for implementing inlining optimizations for memcpy and friends. However, looking around the existing implementation, I don’t see anything that would particularly be problematic for us to do it at the IR level. The existing TLI hooks to specify how certain memcpy calls should be lowered doesn’t have anything too SelectionDAG specific, and an IR

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

I don’t think bfloat should be handled this way. What Amara is suggesting is an optimization, i.e., if we drop the information we are still correct. With bfloat, if we do an operation on float16 instead of bfloat16 this is a correctness problem. So that means that either we need to have new opcodes for bfloat or we need to carry around the floating point type in MIR. I think it would be more

> On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Amara, > >> On Nov 10, 2017, at 9:12 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine

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

Looks like there are a lot of opinions where memcpy expansion/inlining needs to happen: (late) IR, or if it is a backend problem, see also for example https://reviews.llvm.org/D35035. Complicating factor here is that efficient memcpy lowering is crucial for performance and code-size (and they occur a lot). Either way, I agree that the TLI hooks are not SelectionDAG specific, they can be used in

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