search for: regbank

...020, 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 can finalize the regbanks, changing some if it deems it necessary/optimal. > > This seems reasonable to me. It wouldn’t require any new infrastructure How would that work with illegal operations? Would the legalizer...

> 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 willingly dropped doesn’t make sense when the solution can be cheap. I don’t propose that we force the type distinction back, just to allow RBS to make *fast*, reasonably optimal deci...

...pensate, later passes use the FP operations on those values to guess what kind of value is being stored within that virtual register. This means that i32/float loads get translated into the same thing, and only when that value is used, say by an fadd, then will we know that it was an FP value. The regbankselect pass on AArch64 currently tries to walk uses/defs in order to guess what kind fo regbank to assign to vregs. This however doesn’t work all the time, and most commonly, it doesn’t work when a load of an FP value is used in a loop. In that case, the FP users are obscured by PHIs which make it d...

...ater passes use the FP operations on those values to guess what kind of value is being stored within that virtual register. > > This means that i32/float loads get translated into the same thing, and only when that value is used, say by an fadd, then will we know that it was an FP value. The regbankselect pass on AArch64 currently tries to walk uses/defs in order to guess what kind fo regbank to assign to vregs. This however doesn’t work all the time, and most commonly, it doesn’t work when a load of an FP value is used in a loop. In that case, the FP users are obscured by PHIs which make it d...

...ses use the FP operations on those values to guess what kind of value is being stored within that virtual register. >> >> This means that i32/float loads get translated into the same thing, and only when that value is used, say by an fadd, then will we know that it was an FP value. The regbankselect pass on AArch64 currently tries to walk uses/defs in order to guess what kind fo regbank to assign to vregs. This however doesn’t work all the time, and most commonly, it doesn’t work when a load of an FP value is used in a loop. In that case, the FP users are obscured by PHIs which make it d...

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 register bank dedicated to...

...e 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 mappings will certainly be non-trivial however, so I >> wonder if there is a smart way to do this without spending too much >> compilation time. >> &g...

...istof and I have been trying to keep the scratchpad document here [1] up to date, but I'll try to summarize things on the mailing list as well: We still have a few bugs open that we should fix or at least discuss before turning GlobalISel on by default at O0 for AArch64: * PR32560 - A crash in regbank select [2] * PR32550 - Floating point values moving a lot through GPRs [3] * PR32561 - Improve placement of constants [4] * Optional - improve handling of switch statements (I think we don't even have a bug open for this, but it has been brought up) Unrelated to O0, here are some pending patch...

Hi all, At the EuroLLVM BoF people asked where the design discussions around GlobalISel take place. Naturally, a lot of them take place at Apple, since they have the highest density of co-located GlobalISel devs, but we also have some in Phab. For those of you that are interested, please have a look at the following topics - discussions are progressing rather slowly and we definitely

...implement selection for those? Maybe I just didn't read the code properly... > > 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. > I looked at the CC regbank of AArch64, however I didn't see any mappings using it in RegBankInfo. Is that something that AArch64 simply hasn't implemented or is there something going on that I'm not seeing. I mean, what is the point to have a register bank when it is not used during regbankselect? I would at...

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 mappings will certainly be non-trivial however, so I wonder if there is a smart way to do this without spending too much compilation time. Ideally for instructions with no operands (lik...

...not allocatable and copyable and emit a COPY to/from our physical carry bit register. This generally works the way we want and the COPY is eliminated. However it is not eliminated when using O0. I guess this probably has something to do with not defining an extra register bank and teaching our regbank info that such a carry-bit vreg should be assigned to this regbank? Right now it is simply assigned to the GPR bank, which seems to be the problem for O0. Nevertheless I still dislike this approach as I don't want to rely on the COPY being eliminated. I would much rather not emit it at all,...

...out information, and not any information about whether a type is integer or fp, we lose information during IR translation of type overloaded intrinsics. Most of the time, we don’t run into this issue because the generic opcodes distinguish between fp and int operations, and for most intrinsics the regbank can normally disambiguate the operation (e.g. the source operands are assigned either gpr or fpr banks). However, this isn’t enough in the case of vectors on arm64, which can contain both fp and int elements, and if target intrinsics have been defined to use their type overloading to determine the...

...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 'default' mapping to use for 'Fast' RegBankSelect mode? The reason this would make sense (at least for the AMDGPU target) is because both functions need to do the exact same analysis in order to compute the cost and order for the InstrMappings, so we end up with a lot of duplicated computations. -Tom

...not sure we want that at O0 though (even if only for FastISel+DAGISel parity). > I'll try to add the above content to the document Diana created at > https://goo.gl/IS2Bdw too. Thanks for the investigation! These are also some of the biggest problems I've seen (in particular the FP regbanks). I'll make sure I find the time to file bugs for all the other issues I'm aware of. (sorry I haven't done that earlier!) -Ahmed > Thanks, > > Kristof > > > > On 3 Apr 2017, at 17:10, Kristof Beyls <Kristof.Beyls at arm.com> wrote: > > I've kick...

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

> On Behalf Of Nicholas Chapman > > On 04/12/2012 06:29, Michael Spencer wrote: > > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> > wrote: > >> As an update to this: > >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl- > >> exe-ice-when-building-llvm-trunk-at-o2 > >> > >> Microsoft

On 04/12/2012 06:29, Michael Spencer wrote: > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: >> As an update to this: >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 >> >> Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release.

I've kicked off a run to compare "-O0 -g" versus "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2". I've selected the test-suite (albeit a version which is a couple of months old now) and a few short-running proprietary benchmarks to get data back quickly for an initial feel of where things are. This was running on Cortex-A57 AArch64 Linux. I saw one assertion