similar to: GlobalISel round table follow-up: multi-stage legalization

Hi Matt, thanks for responding. I left a couple of comments down below. Am 24.03.20 um 18:26 schrieb Matt Arsenault: > >> On Mar 24, 2020, at 12:24, Dominik Montada via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> recently when working with GlobalISel we have often encountered cases in the legalizer where instructions could not be

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 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, recently when working with GlobalISel we have often encountered cases in the legalizer where instructions could not be narrowed because the narrowing code relies on G_UNMERGE_VALUES and therefore requires the source type to be a multiple of the narrow type. Often times these instructions can be widened without any problem to a fitting type. This has us writing legalization rules like

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 Dominik, Thanks for your reply. In my case, the Defs is the cause of the problem. Or rather, it is part of the problem, because when I remove it from the instruction TableGen gives me a different error message which concerns a part which is deeper into the pattern tree, so at least it is able to proceed beyond that part of the pattern. I have also stepped TableGen inside gdb and

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

Hi Daniel, Thanks for replying; I was hoping to get in touch with you on this issue. I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern: /* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND), /* 3*/ OPC_MoveChild0, /* 4*/ OPC_CheckOpcode,

Hi, We're working on adding exception handling support for a downstream bare-metal target. I read through the LLVM exception handling docs [1] and went through some patches from other backends to understand what parts we need to implement. We're now at a point were it feels like it should work, but unfortunately exceptions are still not getting caught. Our target uses DWARF

Hi all, After a recent upstream merge into our downstream sources we are suddenly encountering the freeze instruction in LLVM IR for div/rem pairs. This seems to be related to [1]. Our downstream target is GlobalISel only and unfortunately GlobalISel doesn't support this instruction yet, so most of our internal test-suite is now breaking due to GlobalISel not being able to translate this

I just landed these patches: commit c55051eea5d3cd57abfd9727f519b670517704d9 Author: Louis Dionne <ldionne at apple.com> Date: Thu Jun 25 12:02:43 2020 -0400 [libunwind] Allow specifying custom Lit config files This is the libunwind counterpart of 0c66af970c80. commit 33c9c10d183371edc95fa936705bef56f55ab611 Author: Louis Dionne <ldionne 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

Hi, I am in the process of porting our target to GlobalISel, and have encountered a problem. Nearly all instructions in our instruction set make modifications to a CC register, and hence are defined as follows: let ..., Defs = [CCReg] in def shfts_a32_imm7: Instruction<(outs OurRC:$dst), ...>; What's more, many of these instructions have patterns where the instruction itself

Hi Louis, sorry for bothering you once more about the libcxx test suite! I was wondering whether you could help with some of my problems again. After the recent discussion on the mailing list and your diff, I was able to set up cross-compilation and remote-execution of the libcxx test suite, so thank you for that! We have split up the build of the libraries into different stages, so libcxx,

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, 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 @ll, I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG combines is skipped and no VSELECT specified optimizations are performed at all. Is there a reason we don’t run the X86 DAG combiner before Type

I see. We still can use that shortcut to catch the simple case after type legalization, but we could also do a more elaborate type check before type legalization to enable it? On Aug 19, 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the

On Mon, Aug 19, 2013 at 4:17 PM, Juergen Ributzka <juergen at apple.com> wrote: > I see. We still can use that shortcut to catch the simple case after type > legalization, but we could also do a more elaborate type check before type > legalization to enable it? > If you're going to write the code to check the types anyway, it's probably clearer to remove the