similar to: Dealing with illegal operand mappings in RegBankSelect

> 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

> On Feb 26, 2019, at 7:25 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > > >> On Feb 26, 2019, at 4:18 PM, Matt Arsenault <arsenm2 at gmail.com <mailto:arsenm2 at gmail.com>> wrote: >> >> >> >>> On Feb 26, 2019, at 7:01 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:

Hi, I’m looking at RegBankSelect’s partially implemented support for deciding to split a value between multiple registers and I’m wondering if it’s actually intended to solve the problem I’m trying to use it for. RegisterBankInfo.h has this example mapping table: /// E.g., /// Let say we have a 32-bit add and a <2 x 32-bit> vadd. We /// can expand the /// <2 x 32-bit> add into

Hi Quentin, I’ve started running an ABI test suite with global isel on AArch64, and while it hasn’t found any ABI issues it has hit an assertion in clang when using the __fp16 type. Here’s a reproducer: __fp16 pass_f16(__fp16 p) { return p; } $ /work/llvm/build/bin/clang --target=aarch64-arm-none-eabi -march=armv8-a -c test.c -O0 -mllvm -global-isel -mllvm -global-isel-abort=0

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

To give an update here, we actually are not missing a mapping. The code complains because we are copying around a fp16 into a gpr32 and that shouldn’t be done with a copy (default mapping). I extended the repairing code to issue G_ANYEXT in those cases instead of asserting. However, now, I have to teach instruction select about those ANYEXT otherwise we’ll fallback in that case. But that’s a

Hi Oliver, Thanks for trying this. Could you file a different PR for each of the problem you found and reference the umbrella PR: http://llvm.org/PR35347? <http://llvm.org/PR35347?> Thanks, -Quentin > On Nov 17, 2017, at 8:17 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > One more reproducer, this time with small (<64bit) values

Hi everyone: I need to count the number of banks of each firm in my data. The firm is identified by the fiscal number. The banks of each firm appears like this: Firm Banks 500600700 Citybank 500600700 CGD 500600700 BES 500600800 Citybank 500600800 Bank1 500600900 CGD I want to obtain the following dataframe: Firm

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

Hi, GlobalISel currently drops all type information relating to the integer/FP distinction during the IR translation pass, as the LLT types only represent whether a value is a scalar/vector/pointer and it’s size/shape. To compensate, 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

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

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

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

> 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, I'm wondering if there's a method for doing any of these 1. Check what's the physical memory available. free -m shows ~768 mem but I was sure that I had 1G of memory in there. 2. I check the kernel and it seems like the 4G split is in effect so it should map / correctly recognise there's 1G of Mem there. Is there any way to check besides opening up the machine to look at it

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

This is a continuation to the library creation effort for syslinux. I added the necessary ops required to read partitions and sectors off the disk. I'm using it with my com32 module. I did change the interface for read_disk a bit, so it takes a disk_info argument. This way I can maintain multiple instances of read handlers, for example if I'm reading and comparing stuff from two different

Hi A few of us have discussed enhancing the MIR vregs to include support for named-vregs. At the moment named regs are only supported for physical registers and number regs are reserved for vregs. We've decided that to properly implement a syntax for MIR named vregs we first need to reorganized the sigils used for physical registers and external symbols so our proposal is to swap the sigil