search for: regbanks

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

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

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

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

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

...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. >> &gt...

Hi again, On 1 April 2017 at 15:09, Diana Picus <diana.picus at linaro.org> wrote: > If people feel it would be useful, we could also try to send a > weekly-ish email listing the pending reviews and any points that need > coordination. We're open to any suggestions on how we can communicate > better. Nobody said anything about this, but with people coming back from spring

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

...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 least expect that for example G_UADDO would use this register bank for the s1 carry out. > > Generally speaking, I think you would need a copy (or zext/sext) to > move the value in general purpose land (like in my example with zext). > If you don’t have such use, 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 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 (like...

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

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

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