search for: g_load

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 and floating point instructions of the sam...

...ve 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? Regards, Igor Breger --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is stri...

...; you described above and needed it to conform to the dag type) but I did like that effect when I saw it written down :-). > [snip] >> _Passing arbitrary data from match to apply_ >> The main change in this section that hasn't already been discussed is that the result of extending_load_predicate has been moved to the new 'outs' section of GIMatchPredicate and the code expansion refers to a particular output of the predicate using 'matchinfo.B' similar to a struct member or multi-operand ComplexPatterns. >> def extending_load_matchdata : GIDefMatchData&lt...

...compare opcode (opcode that requires negation (with xor) could be selected into movz and remove xor (or into movn with but we need to swap true and false register)).  If we select icmp and select independently we could end up with an extra xor instruction. I ask this question since combination of G_LOAD and G_SEXT  %1:_(s8) = G_LOAD %0(p0)  %2:_(s32) = G_SEXT %1(s8) will be replaced with G_SEXTLOAD in upcoming combiner. And if we let  %1:_(s8) = G_LOAD %0(p0) to be legal, we could select G_SEXT into G_LOAD (going bottom up) into sign extending load of appropriate size in instruction-select. Bes...

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

...(apply (create_imm [{ 2 * ${B}->getZExtValue() }], apint_value:$B):$NB, (G_ADD $t1, $A, $A), (G_ADD $D, $t1, $NB))>; Passing arbitrary data from match to apply The main change in this section that hasn't already been discussed is that the result of extending_load_predicate has been moved to the new 'outs' section of GIMatchPredicate and the code expansion refers to a particular output of the predicate using 'matchinfo.B' similar to a struct member or multi-operand ComplexPatterns. def extending_load_matchdata : GIDefMatchData<"P...

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

...lier. Passing arbitrary data from match to apply As mentioned earlier, the defs block defines the interface between the match and apply steps. This can be used to arrange for arbitrary data to be passed from match to apply. In the current AArch64PreLegalizeCombiner we have a rule that matches a G_LOAD and all its uses simultaneously and decides on the best way to rewrite it to minimize the sign/zero/any-extend operations. This rule passes a struct (PreferredTuple) between the current C++ equivalent for the match to the current C++ equivalent to the apply. Converting that into this tablegen synta...

...ch to apply_ >> _ >> _ >> As mentioned earlier, the defs block defines the interface between the match and apply steps. This can be used to arrange for arbitrary data to be passed from match to apply. >> In the current AArch64PreLegalizeCombiner we have a rule that matches a G_LOAD and all its uses simultaneously and decides on the best way to rewrite it to minimize the sign/zero/any-extend operations. This rule passes a struct (PreferredTuple) between the current C++ equivalent for the match to the current C++ equivalent to the apply. Converting that into this tablegen synta...

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

...s, I’m using two different pseudo register banks used for operands that really function as booleans (select/br conditions, compare results, and a few intrinsics). These two banks physically alias the SGPR bank, but contextually function differently than an s1 value from a non-boolean source (e.g. a G_LOAD of s1 or G_TRUNC to s1). G_SELECT (s1 G_LOAD) would be illegal for example without inserting some kind of compare between the load and select boolean use. The primary problem I’m currently aiming to solve is losing this contextual pseudo-register bank information once an instruction is selected, a...

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