search for: aext

...and have problems with the DAG Combiner. The processor architecture supports i1 and i32 registers. 1-bit registers are mainly used as comparison result but basic operations like OR are not possible between i1 registers. So I wrote custom lowering for i1 OR operations and replaced it by (trunc (or (aext x), (aext y))). Now the problem is that the DAG Combiner optimizes it back to an i1 OR operations that is not supported by the architecture. What is the best way to solve this problem? I take a look at the DAG Optimizer and for this OR operation it calls DAGCombiner::SimplifyBinOpWithSameOpcode...

...DAG Combiner. The processor architecture > supports i1 and i32 registers. 1-bit registers are mainly used as > comparison result but basic operations like OR are not possible > between i1 registers. So I wrote custom lowering for i1 OR > operations and replaced it by (trunc (or (aext x), (aext y))). Now > the problem is that the DAG Combiner optimizes it back to an i1 OR > operations that is not supported by the architecture. The IA64 target has just been removed from the tree. It was the only target with legal i1 values, so there could be some problems. The Black...

...DAG Combiner. The processor architecture > supports i1 and i32 registers. 1-bit registers are mainly used as > comparison result but basic operations like OR are not possible > between i1 registers. So I wrote custom lowering for i1 OR > operations and replaced it by (trunc (or (aext x), (aext y))). Now > the problem is that the DAG Combiner optimizes it back to an i1 OR > operations that is not supported by the architecture. The IA64 target has just been removed from the tree. It was the only target with legal i1 values, so there could be some problems. The Black...

...ixed instructions, so there's no point to using W forms > if you don't need the sign extension. Unless MULW has lower latency than > MUL on some CPU? It only matters when it allows you to avoid an unnecessary sext/zext of the input operands. Consider the following input: define i32 @aext_divuw_aext_aext(i32 %a, i32 %b) nounwind { %1 = udiv i32 %a, %b ret i32 %1 } This pattern won't match: def : Pat<(sext_inreg (udiv (zexti32 GPR:$rs1), (zexti32 GPR:$rs2)), i32), (DIVUW GPR:$rs1, GPR:$rs2)>; This pattern would match but is incorrect in the general case (e.g...

On Dec 27, 2008, at 4:30 AM, Sandeep Patel wrote: > Attached is a prototype patch that uses CCState to lower RET nodes in > the ARM target. Lowering CALL nodes will come later. > > This patch does not handle f64 and i64 types. For these types, it > would be ideal to request the conversions below: i64 isn't Legal on ARM, so it should already be handled. > > > def

Attached is a prototype patch that uses CCState to lower RET nodes in the ARM target. Lowering CALL nodes will come later. This patch does not handle f64 and i64 types. For these types, it would be ideal to request the conversions below: def RetCC_ARM_APCS : CallingConv<[ CCIfType<[f32], CCBitConvertToType<i32>>, CCIfType<[f64], CCBitConvertToType<i64>>,

As previously discussed in an RFC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, the RISC-V backend has i64 as the only legal integer type for the RV64 target. Thanks to variable-sized register class support, this means there is no need for duplication of either patterns or instruction definitions for RV32 and RV64. It's worth noting that RV64I is a different base

...OAD $dst, $ptr))>; This isn't quite the same thing as the extending loads combine in the example. In that combine, it's matching the load and all uses of its result and chosing a replacement based on the global usage of that def across the whole function, rewriting conflicting sext/zext/aext/trunc's to be as cheap as possible (a lot of the detail of that is inside the function but the code is upstream if you want to see the details). This rule is matching a single use and relying on CSE to de-dupe the N G_SEXTLOAD's that come out of it. To illustrate the difference, consider:...

..., $ptr))>; >> This isn't quite the same thing as the extending loads combine in the example. In that combine, it's matching the load and all uses of its result and chosing a replacement based on the global usage of that def across the whole function, rewriting conflicting sext/zext/aext/trunc's to be as cheap as possible (a lot of the detail of that is inside the function but the code is upstream if you want to see the details). This rule is matching a single use and relying on CSE to de-dupe the N G_SEXTLOAD's that come out of it. To illustrate the difference, consider: &...

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.