similar to: [GlobalISel][RFC] New verifier stages

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

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

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 all, Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. As explained during the last developer meeting, we are aiming at

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

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

On 12 June 2017 at 18:54, Diana Picus <diana.picus at linaro.org> wrote: > Hi all, > > I added a buildbot [1] running the test-suite with -O0 -global-isel. It > runs into the same 2 timeouts that I reported previously on this thread > (paq8p and scimark2). It would be nice to make it green before flipping the > switch. > > I did some more investigations on a machine

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

Hi, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

Hi, I would like to get rid of the logic around disabling GlobalISel from the build. *** Context *** So far, GlobalISel has been this framework built up on the side for about two years. Now, we are close to a point where having it being optional impedes our ability to implement the right things. For instance, checks that would fit naturally in the MachineVerifier are directly done during the

Hi, With this email, I would like to kick-off the development for the next instruction selector that I described during the last LLVM Dev’ Meeting. For the motivations, see Jakob’s proposal (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html>) and for the proposal, see the slides (Keynote:

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 all, I've been investigating a machine verifier failure on the attached testcase, and I'm tempted to say the verifier is wrong and should accept it. Skip the description for the proposed change. On AArch64, the verifier complains with: *** Bad machine code: MBB exits via unconditional branch but doesn't have exactly one CFG successor! *** - function: t4 - basic

Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect this for me.

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

Hi David, > On Nov 18, 2015, at 11:55 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > Hi Quentin, > > On 18 Nov 2015, at 19:26, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> In the section “Goals", I defined (repeated for people that saw the talk) the goals for the Global ISel design. >> - Do you see

Hi Daniel, I had a quick look at the language reference for bitcast and I have a different reading than what you were pointing out. Indeed, my take away is: "It is always a no-op cast because no bits change with this conversion." In other words, deleting all bitcast instructions should be fine. My understanding of the quote you’ve highlighted is that it tells C programmers that this