similar to: RFC: [GlobalISel] propagating int/float type information

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

> On May 1, 2020, at 10:28 AM, Arsenault, Matthew <Matthew.Arsenault at amd.com> wrote: > > [AMD Public Use] > > > It seems to me like you're looking for a workaround for the fact that nobody has put any serious optimization effort into RegBankSelect Practically speaking, we have a compile time budget, and spending that on reconstructing information which we

Hi, Mips32 has 64 bit floating point instructions, while i64 instructions have to be emulated with i32 instructions. This means that G_LOAD should be custom legalized for s64 integer value, and be legal for s64 floating point value. There are also other generic instructions with the same problem: G_STORE, G_SELECT, G_EXTRACT, and G_INSERT. There are also other configurations where integer

> On May 4, 2020, at 2:01 PM, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On May 1, 2020, at 14:00, Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> wrote: >> >> The other thing we could do is to assign speculative regbanks to vregs during translation (if the target wants to opt-in), and then RBS

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

Hi, I’m trying to handle some vector operations with splitting/scalarization and keep running into similar sorts of issues which are making me question the intended function of the various legalization operations (particularly G_MERGE_VALUES/G_UNMERGE_VALUES, but also G_EXTRACT/G_INSERT and conversion instructions) and what the contract between the legalizer and selector actually is. For scalar

Hi, I’ve been thinking about what the strategy to use for boolean values in GlobalISel. There are a few semantic and mechanical issues I’ve encountered. For background, on AMDGPU, there are two kinds of bool/s1 values. Contextually, a real boolean value will either be a 1-bit scalar condition (in a non-allocatable physical condition register, which will need to be copied to an allocatable class

Hi Quentin, thank you for the reply! This clears up a lot of the questions I was having. It seems like we should definitely invest some time in rewriting some of our legalization rules then! I also posted some questions further down below. I would appreciate getting your opinion on them. > Hi Dominik, > > I’ll do a brief reply here and if you want more information we can talk further

Hi all, this is the second email for the round table follow-up, this time regarding the issues around the greedy RegBankSelect and alternative mappings. The issue I brought up was that because RegBankSelect goes top-down, it never looks at all available mappings for the operands when considering which of the mappings to apply to the current instruction. In our architecture we have one

Hi Quentin, Am 08.10.20 um 21:17 schrieb Quentin Colombet: > Hi Dominik, > >> On Oct 8, 2020, at 5:03 AM, Dominik Montada >> <dominik.montada at hightec-rt.com >> <mailto:dominik.montada at hightec-rt.com>> wrote: >> >> Hi Quentin, >> >> thanks for picking up the conversation! >> >> > I think we should step back and

Hi, I've spent some time playing around with GlobalISel on the AMDGPU target, and I was wondering if there is any reason to have RegisterBankInfo::getInstrAlternativeMappings() and RegisterBankInfo::getInstrMapping() as separate functions. Could we instead replace these two functions with just one: RegisterBankInfo::getInstrMappings() and then just treat the first mapping in the list as the

Hi Quentin, thanks for picking up the conversation! > I think we should step back and check what we want before investing any time in some rewrite. That is a very fair point and I might have been getting ahead of myself in my last email. What I would like to see from RegBankSelect is to produce the mapping with the overall lowest cost. Keeping track of all different combinations of

Hi Quentin, thank you for the reply! I have a couple more questions that came up when I tried to implement this today. I hope you can help me out with this again! Am 09.03.20 um 23:31 schrieb Quentin Colombet: > I would expect that you could create a register class and register > bank for the special register. That way you have something to map to > when you do register bank select.

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

Hi Quentin, Hi Amara, I was following your discussion on D75086 regarding declaring types as legal even if they are smaller than the actual register class (e.g. s16 and gpr32). We are working on a backend which only has 32 and 64-bit registers and we recently had a problem regarding exactly this where we had to declare G_UNMERGE_VALUES and G_MERGE_VALUES with a smaller type of <s32 as

Hi, I've been experimenting with global isel over the last few weeks and it is such a vast improvement over the SelectionDAG for the AMDGPU target that I would really like to begin using it as soon as possible. Given the lack of a replacement for SelectionDAG's legalizer / combiner, and how much work this will be to implement, I think the fastest path to doing this would be to run some

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

> On Feb 21, 2019, at 12:18 AM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Matt, > >> On Feb 20, 2019, at 4:49 PM, Arsenault, Matthew via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> Some operations on AMDGPU require operands which must be in a register

Hi, Some operations on AMDGPU require operands which must be in a register bank that is impossible to copy from another. The operation needs to be rewritten in a complex way to avoid the illegal copy. Currently if I correctly report the required register banks in the operand mapping, RegBankSelect happily inserts the illegal copies, somehow concluding they are cheap (I would at least hope