mirror of
https://github.com/ROCm/ROCm.git
synced 2026-04-05 03:01:17 -04:00
[RemoveLayoutConversions] Remove PatternSharedInfo structure (#378)
This structure is not used anymore after massive refactoring of RemoveLayoutConversion pass in September IFU.
This commit is contained in:
@@ -27,24 +27,6 @@ using triton::gpu::DotOperandEncodingAttr;
|
||||
using triton::gpu::MmaEncodingAttr;
|
||||
using triton::gpu::SliceEncodingAttr;
|
||||
|
||||
struct PatternSharedInfo {
|
||||
// If a conversion cannot be eliminated with a high-benefit pattern (e.g.,
|
||||
// SimplifyConversion, RematerializeBackward), it will be pushed forward in
|
||||
// the hope that this will enable the elimination of these conversions later.
|
||||
// However, pushing a conversion forward can introduce more conversions
|
||||
// (op(cvt(arg_0), arg_1, ..., arg_n) -> cvt(op(arg_0, cvt(arg_1), ...,
|
||||
// cvt(arg_n))). This is why the RematerializeForward pattern performs an
|
||||
// analysis to determine whether these added conversions can be eliminated
|
||||
// later. The RematerializeBackward pattern, applied after pushing this
|
||||
// conversion forward, will eliminate these newly added conversions by
|
||||
// reversing the process achieved with RematerializeForward. This can create
|
||||
// an infinite loop between these two optimizations. To avoid this, we keep
|
||||
// track of the conversions that were pushed forward and skip them in the
|
||||
// RematerializeBackward pattern. A similar kind of loop can occur with the
|
||||
// RematerializeForward and MoveConvertOutOfLoop patterns.
|
||||
llvm::DenseMap<Operation *, Operation *> cvtsPushedForwardMap;
|
||||
};
|
||||
|
||||
// -----------------------------------------------------------------------------
|
||||
//
|
||||
// -----------------------------------------------------------------------------
|
||||
|
||||
Reference in New Issue
Block a user