| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][acc] Add OpenACCSupport for extensible dialect handling (#164510) The OpenACC dialect must coexist with source language dialects (FIR, CIR, etc.) to enable offloading. While type interfaces ( PointerLikeType and MappableType) provide the primary contract for variable mapping, some scenarios require pipeline-specific customization or need to express information that cannot be adequately captured through operation and type interfaces alone. This commit introduces the OpenACCSupport analysis, which provides extensible support APIs that can be customized per-pipeline. The analysis follows the Concept-Model pattern used in MLIR's AliasAnalysis and is never invalidated, persisting throughout the pass pipeline. The initial API, getVariableName(Value) -> string, retrieves variable names from MLIR values by: - Checking for acc.var_name attributes - Extracting names from ACC data clause operations (e.g., acc.copyin) - Walking through ViewLikeOpInterface operations to find the source This will be used in the implicit data mapping pass to automatically generate device mappings with correct user-visible variable names. Usage: Passes call getAnalysis<OpenACCSupport>() to get a cached instance with either the default or a previously- registered custom implementation. Custom implementations can be registered in a setup pass by calling setImplementation() before the consumer pass runs. | 9 个月前 | |
[mlir][acc] Add OpenACCSupport for extensible dialect handling (#164510) The OpenACC dialect must coexist with source language dialects (FIR, CIR, etc.) to enable offloading. While type interfaces ( PointerLikeType and MappableType) provide the primary contract for variable mapping, some scenarios require pipeline-specific customization or need to express information that cannot be adequately captured through operation and type interfaces alone. This commit introduces the OpenACCSupport analysis, which provides extensible support APIs that can be customized per-pipeline. The analysis follows the Concept-Model pattern used in MLIR's AliasAnalysis and is never invalidated, persisting throughout the pass pipeline. The initial API, getVariableName(Value) -> string, retrieves variable names from MLIR values by: - Checking for acc.var_name attributes - Extracting names from ACC data clause operations (e.g., acc.copyin) - Walking through ViewLikeOpInterface operations to find the source This will be used in the implicit data mapping pass to automatically generate device mappings with correct user-visible variable names. Usage: Passes call getAnalysis<OpenACCSupport>() to get a cached instance with either the default or a previously- registered custom implementation. Custom implementations can be registered in a setup pass by calling setImplementation() before the consumer pass runs. | 9 个月前 | |
[acc] Expand OpenACCSupport to provide getRecipeName and emitNYI (#165628) Extends OpenACCSupport utilities to include recipe name generation and error reporting for unsupported features, providing foundation for variable privatization handling. Changes: - Add RecipeKind enum (private, firstprivate, reduction) for APIs that request a specific kind of recipe - Add getRecipeName() API to OpenACCSupport and OpenACCUtils that generates recipe names from types (e.g., "privatization_memref_5x10xf32_") - Add emitNYI() API to OpenACCSupport for graceful handling of not-yet-implemented cases - Generalize MemRefPointerLikeModel template to support UnrankedMemRefType - Add unit tests and integration tests for new APIs | 9 个月前 | |
[mlir][acc] Introduce createAndPopulate for recipe creation (#162917) Private and firstprivate recipes can now be created and populated through the createAndPopulate method. The populating of recipe bodies is done through using the PointerLikeType and MappableType interfaces (with MappableType support still in progress). The existing create() API remains available for cases where dialects need manual recipe population (e.g., for frontend-specific semantics like default value initialization or constructor calls). Testing exercises the new API with memref types. | 9 个月前 | |
[mlir][acc] Introduce createAndPopulate for recipe creation (#162917) Private and firstprivate recipes can now be created and populated through the createAndPopulate method. The populating of recipe bodies is done through using the PointerLikeType and MappableType interfaces (with MappableType support still in progress). The existing create() API remains available for cases where dialects need manual recipe population (e.g., for frontend-specific semantics like default value initialization or constructor calls). Testing exercises the new API with memref types. | 9 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 |