similar to: [GlobalISel] G_LOAD/G_STORE i64/f64 handling

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

> 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

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

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

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

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 , Currently GobalIsel like FastIsel designed to use fallback to DAGIsel in case of failure. You can use -global-isel-abort=2 option. llc -global-isel -pass-remarks-missed="gisel-*" -global-isel-abort=2 simple_foo.ll Regards, Igor From: S. Bharadwaj Yadavalli [mailto:bharadwajy at gmail.com] Sent: Thursday, November 09, 2017 03:36 To: Aditya Nandakumar <proaditya at

> 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

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 All, 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 email ended up rather long so: 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.

Looking through the X86 GlobalISEL code for selecting loads and stores, I'm not seeing the creation of the MachineMemOperands I'd expect to see and do see being generated by SelectionDAG.  Is this simply an oversight, or is there some aspect of the new design which pushes us away from MMOs? Various parts of the machine instruction level optimization passes use the existence and

I tried to retrieve anything from DataLayout. It contains pointer size, but how can I conclude that the GEP index can't be widened? - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, January 15, 2018 20:34 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) <spatel at

On 01/15/2018 12:59 PM, Demikhovsky, Elena wrote: > > I tried to retrieve anything from DataLayout. It contains pointer > size, but how can I conclude that the GEP index can’t be widened? > I meant that we'd add a new field giving the preferred size for indexing arithmetic.  On the other hand, in your case, and in general, would it make sense to prevent widening beyond the largest

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

I believe if you pass(iirc) -pass-remarks-missed=“gisel-*”, it’ll print the instruction it failed to legalize. Sent from my iPhone > On Oct 11, 2017, at 6:44 PM, S. Bharadwaj Yadavalli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks for your quick reply. > > Here its is: > > =========== > > ; ModuleID = 'simple_foo.c' > source_filename

Hi Ahmed, >From what can be seen in the code snippet you provided, the reuse of XMM0 and XMM1 across loop-unroll instances does not inhibit instruction-level parallelism. Modern X86 processors use register renaming that can eliminate the dependencies in the instruction stream. In the example you provided, the processor should be able to identify the 2-vloads + vadd + vstore sequences as

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

Hi, Zvi, I agree. In the context of targeting the KNL, however, I'm a bit concerned about the addressing, and specifically, the size of the resulting encoding: > vmovdqu32 zmm0, zmmword ptr [rax + c+401280] ;load b[401280] in > zmm0 > > vpaddd zmm1, zmm1, zmmword ptr [rax + b+401344] > ; zmm1<-zmm1+b[401344] The KNL can only