search for: g_loads

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 all, I am working on enabling X86 using GLobalIsel framework. I have 32bit platform + float/double configuration (-mtriple=i386-linux-gnu -mattr=+sse2 ) load i64, i64* %p1 - illegal, require narrowScalar action load double, double * %p1 - legal What is the best approach to Legalize this case ? Should I mark G_LOAD/G_STORE s64 as Custom?

...tchData<"PreferredTuple">; >> def extending_load_predicate : GIMatchPredicate< >> bool, (ins reg:$A), (outs extending_load_matchdata:$B), [{ >> return Helper.matchCombineExtendingLoads(${A}, ${B}); >> }]>; >> def extending_loads : GICombineRule< >> (defs operand:$D, reg:$A, extending_load_matchdata:$matchinfo), >> (match (G_LOAD $D, $A), >> (extending_load_predicate operand:$A, >> extending_load_matchdata:$matchinfo)), >>...

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

...D, $t1, $C)), (apply (create_imm [{ 2 * ${B}->getZExtValue() }], apint_value:$B):$NB, (G_ADD $t1, $A, $A), (G_ADD $D, $t1, $NB))>; // $D is needed because we wanted operand instead of reg. We could rewrite the predicate to take a reg though. def extending_loads : GICombineRule< (defs operand:$D, reg:$A, extending_load_matchdata:$matchinfo), (match (G_LOAD $D, $A), (extending_load_predicate operand:$A, extending_load_matchdata:$matchinfo)), (apply (exec [{ Helper.applyCombineExtending...

.... def extending_load_matchdata : GIDefMatchData<"PreferredTuple">; def extending_load_predicate : GIMatchPredicate< bool, (ins reg:$A), (outs extending_load_matchdata:$B), [{ return Helper.matchCombineExtendingLoads(${A}, ${B}); }]>; def extending_loads : GICombineRule< (defs operand:$D, reg:$A, extending_load_matchdata:$matchinfo), (match (G_LOAD $D, $A), (extending_load_predicate operand:$A, extending_load_matchdata:$matchinfo)), (apply (exec [{ Helper.applyCombineExtending...

...C)), >> (apply (create_imm [{ 2 * ${B}->getZExtValue() }], apint_value:$B):$NB, >> (G_ADD $t1, $A, $A), >> (G_ADD $D, $t1, $NB))>; >> // $D is needed because we wanted operand instead of reg. We could rewrite the predicate to take a reg though. >> def extending_loads : GICombineRule< >> (defs operand:$D, reg:$A, extending_load_matchdata:$matchinfo), >> (match (G_LOAD $D, $A), >> (extending_load_predicate operand:$A, >> extending_load_matchdata:$matchinfo)), >> (apply (exec [{ Helper.applyCombineExtendingLoads(${D}, ${matchinfo.B...

...: def extending_load_matchdata : GIDefMatchData<"PreferredTuple">; def extending_load_predicate : GIMatchPredicate< (ins reg:$A, extending_load_matchdata:$B), bool, [{ return Helper.matchCombineExtendingLoads(${A}, ${matchinfo}); }]>; def extending_loads : GICombineRule< (defs root:$root, reg:$A, extending_load_matchdata:$matchinfo), (match [{MIR %root = G_LOAD %A }], (extending_load_predicate root:$A, extending_load_matchdata:$matchinfo)), (apply (exec [{ Helper.applyCombineE...

...equires fewer argument registers, the second version has to store the MachineOperand* on the stack to pass it by reference. The difference is fairly small when considered on an individual rule but should accumulate on large rulesets or large functions. >> }]>; >> def extending_loads : GICombineRule< >> (defs root:$root, reg:$A, extending_load_matchdata:$matchinfo), >> (match [{MIR %root = G_LOAD %A }], >> (extending_load_predicate root:$A, >> extending_load_matchdata:$matchinfo)), >&...

...erand being matched instead of the operand returned by the predicate will be a common mistake otherwise: let ApplyCannotUseMatchedOperand = 1; I'd also be inclined to make it a warning for this to be unset if the result has a name. >>>> }]>; >>>> def extending_loads : GICombineRule< >>>> (defs root:$root, reg:$A, extending_load_matchdata:$matchinfo), >>>> (match [{MIR %root = G_LOAD %A }], >>>> (extending_load_predicate root:$A, >>>> extending_lo...

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

...’ve had this kind of issue, and it probably won’t be the last [1]. propose that we have some form of type hint propagation done at the IRTranslator stage in order to make this whole situation easier (and faster in compile-time). Option 1) We use some form of metadata on the MIR instructions like G_LOADs to signify that the vreg defined likely has an FP IR type. IIUC the current Metadata MachineOperand type is only intended for debug info. This approach is probably the cheapest in compile time/complexity and is the least invasive, but we’d need to find somewhere in MachineInstr to store this extra...

...his kind of issue, and it probably won’t be the last [1]. propose that we have some form of type hint propagation done at the IRTranslator stage in order to make this whole situation easier (and faster in compile-time). > > Option 1) We use some form of metadata on the MIR instructions like G_LOADs to signify that the vreg defined likely has an FP IR type. IIUC the current Metadata MachineOperand type is only intended for debug info. This approach is probably the cheapest in compile time/complexity and is the least invasive, but we’d need to find somewhere in MachineInstr to store this extra...

...of issue, and it probably won’t be the last [1]. propose that we have some form of type hint propagation done at the IRTranslator stage in order to make this whole situation easier (and faster in compile-time). >> >> Option 1) We use some form of metadata on the MIR instructions like G_LOADs to signify that the vreg defined likely has an FP IR type. IIUC the current Metadata MachineOperand type is only intended for debug info. This approach is probably the cheapest in compile time/complexity and is the least invasive, but we’d need to find somewhere in MachineInstr to store this extra...

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

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

...is kind of issue, and it probably won’t be the last [1]. propose that we have some form of type hint propagation done at the IRTranslator stage in order to make this whole situation easier (and faster in compile-time). > > Option 1) We use some form of metadata on the MIR instructions like G_LOADs to signify that the vreg defined likely has an FP IR type. IIUC the current Metadata MachineOperand type is only intended for debug info. This approach is probably the cheapest in compile time/complexity and is the least invasive, but we’d need to find somewhere in MachineInstr to store this extra...