similar to: [RFC] Tablegen-erated GlobalISel Combine Rules

Hi All, I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where things get a a little awkward (mainly debug info) but things generally look good to me. A Simple Example def : GICombineRule<(defs reg:$D, reg:$S),

...Continued from the other email Removing the defs section We can potentially infer quite a lot of the defs section but it requires both a complicated ruleset and that tblgen spends processing time doing the inferencing. That processing time is potentially significant for large combiners and for that reason we need to be careful not to let inferencing become a burden on tblgen. My main worry

> On Nov 29, 2018, at 02:02, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > On 27.11.18 19:01, Daniel Sanders wrote: >> ...Continued from the other email >> _Removing the defs section_ >> We can potentially infer quite a lot of the defs section but it requires both a complicated ruleset and that tblgen spends processing time doing the inferencing. That

> On Nov 29, 2018, at 01:57, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > > On 27.11.18 18:59, Daniel Sanders wrote: >> I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where

> On Nov 10, 2018, at 03:28, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Thank you for the detailed reply! There's a lot to digest :) Let me try to address most of it. > > > [snip] >>> I also think you should have 'ins' and 'outs' separately; after all, a predicate may have to do a combined check on two matched registers / operands,

Thanks Nicolai! > On Nov 9, 2018, at 02:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > Lots of good stuff in there! I especially like the design for specifying out-of-line predicates. I have a couple of small comments and one major one below. > > > On 09.11.18 02:42, Daniel Sanders via llvm-dev wrote: >> _Passing arbitrary data from

Hello, I am developing GlobalISel for MIPS. I have a few questions and observations about defining legality of generic instruction and also possible combining of instructions and artifacts in pre/post legalizer combiner or elsewhere (e.g. in some sort of instruction-select patterns). I look at legality as "If generic instruction can be selected into machine instruction, it is legal".

Hi Daniel, Disclaimer: Haven't read the proposal yet. > TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to. Eventually, ISel rules may follow suit. I would rather avoid adding a dependency on yet another tablegen backend to the project unless we are confident it is

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

Thanks David! > On Nov 9, 2018, at 08:36, David Greene <dag at cray.com> wrote: > > Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> I've been working on the GlobalISel combiner recently and I'd like to >> share the plan for how Combine Rules will be defined in GlobalISel and >> solicit feedback on it. > > This is

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 Daniel, On 13.09.2018. 19:32, Daniel Sanders wrote: > Could you clarify what you mean here? The new legalizer info can > define this with: >     getActionDefinitionsBuilder(G_SELECT).clampScalar(1, s32, s32) > so I'm guessing you mean that code to mutate the G_SELECT is currently > missing Yes, LegalizerHelper::widenScalar widens only TypeIdx==0, it doesn't do that

> On May 20, 2019, at 10:04, Quentin Colombet <qcolombet at apple.com> wrote: > > +gisel folks > > Hi Alex, > > You’re doing the right thing. > That’s a known limitation that we’ve discussed in https://reviews.llvm.org/D59227 <https://reviews.llvm.org/D59227> but we didn’t really reach a conclusion back them. > Short term, I believe you’re right, we should

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 Daniel, Thanks for the reply! Le lun. 26 nov. 2018 à 10:00, Daniel Sanders <daniel_l_sanders at apple.com> a écrit : > > Hi Quentin, > > Sorry for the slow reply. > > > On Nov 16, 2018, at 09:25, Quentin Colombet <quentin.colombet at gmail.com> wrote: > > > > Hi Daniel, > > > > I finally read the proposal. > > > > I have a

Hi Daniel, Let me try to clarify my concern. Le mar. 27 nov. 2018 à 14:23, Daniel Sanders <daniel_l_sanders at apple.com> a écrit : > > > > On Nov 26, 2018, at 10:11, Quentin Colombet <quentin.colombet at gmail.com> wrote: > > Hi Daniel, > > Thanks for the reply! > > Le lun. 26 nov. 2018 à 10:00, Daniel Sanders > <daniel_l_sanders at apple.com>

I’m less interested in literally passing the output of one as an argument to the next such that argument evaluation order matters. Intermediate register variables are fine. It would still be less code to have tmp = buildFoo(), buildFoo(tmp) than the current code required to manage the register -Matt From: <daniel_l_sanders at apple.com> on behalf of Daniel Sanders <daniel_l_sanders at

Hi, I’m finding the API for MachineIRBuilder to be pretty annoying to use compared to SelectionDAG. I think it’s making the majority of code more verbose and unwieldly for anything less than trivial. I think changing it to behave more like the DAG.get* functions would make it easier to use, and decrease the mental overhead when porting code from SelectionDAG. The main issue is needing to create

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

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