Skip to content

Commit b3eac1a

Browse files
authored
[MLIR][Doc] Remove LLVM dialect typed pointer documentation (#71246)
This commit removes all references to typed pointers. Typed pointers have been deprecated for a while now and they will be removed in a followup. Related PSA: https://discourse.llvm.org/t/psa-removal-of-typed-pointers-from-the-llvm-dialect/74502
1 parent 3d87043 commit b3eac1a

File tree

12 files changed

+134
-175
lines changed

12 files changed

+134
-175
lines changed

mlir/docs/Dialects/LLVM.md

Lines changed: 17 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -210,9 +210,9 @@ style for types with nested angle brackets and keyword specifiers rather than
210210
using different bracket styles to differentiate types. Types inside the angle
211211
brackets may omit the `!llvm.` prefix for brevity: the parser first attempts to
212212
find a type (starting with `!` or a built-in type) and falls back to accepting a
213-
keyword. For example, `!llvm.ptr<!llvm.ptr<i32>>` and `!llvm.ptr<ptr<i32>>` are
214-
equivalent, with the latter being the canonical form, and denote a pointer to a
215-
pointer to a 32-bit integer.
213+
keyword. For example, `!llvm.struct<(!llvm.ptr, f32)>` and
214+
`!llvm.struct<(ptr, f32)>` are equivalent, with the latter being the canonical
215+
form, and denote a struct containing a pointer and a float.
216216

217217
### Built-in Type Compatibility
218218

@@ -232,8 +232,8 @@ compatibility check.
232232

233233
Each LLVM IR type corresponds to *exactly one* MLIR type, either built-in or
234234
LLVM dialect type. For example, because `i32` is LLVM-compatible, there is no
235-
`!llvm.i32` type. However, `!llvm.ptr<T>` is defined in the LLVM dialect as
236-
there is no corresponding built-in type.
235+
`!llvm.i32` type. However, `!llvm.struct<(T, ...)>` is defined in the LLVM
236+
dialect as there is no corresponding built-in type.
237237

238238
### Additional Simple Types
239239

@@ -263,24 +263,19 @@ the element type, which can be either compatible built-in or LLVM dialect types.
263263

264264
Pointer types specify an address in memory.
265265

266-
Both opaque and type-parameterized pointer types are supported.
267-
[Opaque pointers](https://llvm.org/docs/OpaquePointers.html) do not indicate the
268-
type of the data pointed to, and are intended to simplify LLVM IR by encoding
269-
behavior relevant to the pointee type into operations rather than into types.
270-
Non-opaque pointer types carry the pointee type as a type parameter. Both kinds
271-
of pointers may be additionally parameterized by an address space. The address
272-
space is an integer, but this choice may be reconsidered if MLIR implements
273-
named address spaces. The syntax of pointer types is as follows:
266+
Pointers are [opaque](https://llvm.org/docs/OpaquePointers.html), i.e., do not
267+
indicate the type of the data pointed to, and are intended to simplify LLVM IR
268+
by encoding behavior relevant to the pointee type into operations rather than
269+
into types. Pointers can optionally be parametrized with an address space. The
270+
address space is an integer, but this choice may be reconsidered if MLIR
271+
implements named address spaces. The syntax of pointer types is as follows:
274272

275273
```
276274
llvm-ptr-type ::= `!llvm.ptr` (`<` integer-literal `>`)?
277-
| `!llvm.ptr<` type (`,` integer-literal)? `>`
278275
```
279276

280-
where the former case is the opaque pointer type and the latter case is the
281-
non-opaque pointer type; the optional group containing the integer literal
282-
corresponds to the memory space. All cases are represented by `LLVMPointerType`
283-
internally.
277+
where the optional group containing the integer literal corresponds to the
278+
address space. All cases are represented by `LLVMPointerType` internally.
284279

285280
#### Array Types
286281

@@ -346,7 +341,7 @@ syntax:
346341

347342
Note that the sets of element types supported by built-in and LLVM dialect
348343
vector types are mutually exclusive, e.g., the built-in vector type does not
349-
accept `!llvm.ptr<i32>` and the LLVM dialect fixed-width vector type does not
344+
accept `!llvm.ptr` and the LLVM dialect fixed-width vector type does not
350345
accept `i32`.
351346

352347
The following functions are provided to operate on any kind of the vector types
@@ -367,12 +362,11 @@ compatible with the LLVM dialect:
367362

368363
```mlir
369364
vector<42 x i32> // Vector of 42 32-bit integers.
370-
!llvm.vec<42 x ptr<i32>> // Vector of 42 pointers to 32-bit integers.
365+
!llvm.vec<42 x ptr> // Vector of 42 pointers.
371366
!llvm.vec<? x 4 x i32> // Scalable vector of 32-bit integers with
372367
// size divisible by 4.
373368
!llvm.array<2 x vector<2 x i32>> // Array of 2 vectors of 2 32-bit integers.
374-
!llvm.array<2 x vec<2 x ptr<i32>>> // Array of 2 vectors of 2 pointers to 32-bit
375-
// integers.
369+
!llvm.array<2 x vec<2 x ptr>> // Array of 2 vectors of 2 pointers.
376370
```
377371

378372
### Structure Types
@@ -421,21 +415,6 @@ type-or-ref ::= <any compatible type with optional !llvm.>
421415
| `!llvm.`? `struct<` string-literal `>`
422416
```
423417

424-
The body of the identified struct is printed in full unless the it is
425-
transitively contained in the same struct. In the latter case, only the
426-
identifier is printed. For example, the structure containing the pointer to
427-
itself is represented as `!llvm.struct<"A", (ptr<"A">)>`, and the structure `A`
428-
containing two pointers to the structure `B` containing a pointer to the
429-
structure `A` is represented as `!llvm.struct<"A", (ptr<"B", (ptr<"A">)>,
430-
ptr<"B", (ptr<"A">))>`. Note that the structure `B` is "unrolled" for both
431-
elements. _A structure with the same name but different body is a syntax error._
432-
**The user must ensure structure name uniqueness across all modules processed in
433-
a given MLIR context.** Structure names are arbitrary string literals and may
434-
include, e.g., spaces and keywords.
435-
436-
Identified structs may be _opaque_. In this case, the body is unknown but the
437-
structure type is considered _initialized_ and is valid in the IR.
438-
439418
#### Literal Structure Types
440419

441420
Literal structures are uniqued according to the list of elements they contain,
@@ -460,11 +439,10 @@ elements provided.
460439
!llvm.struct<packed (i8, i32)> // packed struct
461440
!llvm.struct<"a"> // recursive reference, only allowed within
462441
// another struct, NOT allowed at top level
463-
!llvm.struct<"a", ptr<struct<"a">>> // supported example of recursive reference
464442
!llvm.struct<"a", ()> // empty, named (necessary to differentiate from
465443
// recursive reference)
466444
!llvm.struct<"a", opaque> // opaque, named
467-
!llvm.struct<"a", (i32)> // named
445+
!llvm.struct<"a", (i32, ptr)> // named
468446
!llvm.struct<"a", packed (i8, i32)> // named, packed
469447
```
470448

mlir/docs/SPIRVToLLVMDialectConversion.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -45,7 +45,7 @@ A SPIR-V pointer also takes a Storage Class. At the moment, conversion does
4545

4646
SPIR-V Dialect | LLVM Dialect
4747
:-------------------------------------------: | :-------------------------:
48-
`!spirv.ptr< <element-type>, <storage-class> >` | `!llvm.ptr<<element-type>>`
48+
`!spirv.ptr< <element-type>, <storage-class> >` | `!llvm.ptr`
4949

5050
### Array types
5151

@@ -443,7 +443,7 @@ order to go through the pointer.
443443
%i = ...
444444
%var = ...
445445
%0 = llvm.mlir.constant(0 : i32) : i32
446-
%el = llvm.getelementptr %var[%0, %i, %i] : (!llvm.ptr<struct<packed (f32, array<4 x f32>)>>, i32, i32, i32)
446+
%el = llvm.getelementptr %var[%0, %i, %i] : (!llvm.ptr, i32, i32, i32), !llvm.struct<packed (f32, array<4 x f32>)>
447447
```
448448

449449
#### `spirv.Load` and `spirv.Store`
@@ -453,16 +453,16 @@ These ops are converted to their LLVM counterparts: `llvm.load` and
453453
following cases, based on the value of the attribute:
454454

455455
* **Aligned**: alignment is passed on to LLVM op builder, for example: `mlir
456-
// llvm.store %ptr, %val {alignment = 4 : i64} : !llvm.ptr<f32> spirv.Store
456+
// llvm.store %ptr, %val {alignment = 4 : i64} : !llvm.ptr spirv.Store
457457
"Function" %ptr, %val ["Aligned", 4] : f32`
458458
* **None**: same case as if there is no memory access attribute.
459459

460460
* **Nontemporal**: set `nontemporal` flag, for example: `mlir // %res =
461-
llvm.load %ptr {nontemporal} : !llvm.ptr<f32> %res = spirv.Load "Function"
461+
llvm.load %ptr {nontemporal} : !llvm.ptr %res = spirv.Load "Function"
462462
%ptr ["Nontemporal"] : f32`
463463

464464
* **Volatile**: mark the op as `volatile`, for example: `mlir // %res =
465-
llvm.load volatile %ptr : !llvm.ptr<f32> %res = spirv.Load "Function" %ptr
465+
llvm.load volatile %ptr : !llvm.ptr f32> %res = spirv.Load "Function" %ptr
466466
["Volatile"] : f32` Otherwise the conversion fails as other cases
467467
(`MakePointerAvailable`, `MakePointerVisible`, `NonPrivatePointer`) are not
468468
supported yet.
@@ -491,7 +491,7 @@ spirv.module Logical GLSL450 {
491491
module {
492492
llvm.mlir.global private @struct() : !llvm.struct<packed (f32, [10 x f32])>
493493
llvm.func @func() {
494-
%0 = llvm.mlir.addressof @struct : !llvm.ptr<struct<packed (f32, [10 x f32])>>
494+
%0 = llvm.mlir.addressof @struct : !llvm.ptr
495495
llvm.return
496496
}
497497
}
@@ -535,13 +535,13 @@ Also, at the moment initialization is only possible via `spirv.Constant`.
535535
```mlir
536536
// Conversion of VariableOp without initialization
537537
%size = llvm.mlir.constant(1 : i32) : i32
538-
%res = spirv.Variable : !spirv.ptr<vector<3xf32>, Function> => %res = llvm.alloca %size x vector<3xf32> : (i32) -> !llvm.ptr<vec<3 x f32>>
538+
%res = spirv.Variable : !spirv.ptr<vector<3xf32>, Function> => %res = llvm.alloca %size x vector<3xf32> : (i32) -> !llvm.ptr
539539
540540
// Conversion of VariableOp with initialization
541541
%c = llvm.mlir.constant(0 : i64) : i64
542542
%c = spirv.Constant 0 : i64 %size = llvm.mlir.constant(1 : i32) : i32
543-
%res = spirv.Variable init(%c) : !spirv.ptr<i64, Function> => %res = llvm.alloca %[[SIZE]] x i64 : (i32) -> !llvm.ptr<i64>
544-
llvm.store %c, %res : !llvm.ptr<i64>
543+
%res = spirv.Variable init(%c) : !spirv.ptr<i64, Function> => %res = llvm.alloca %[[SIZE]] x i64 : (i32) -> !llvm.ptr
544+
llvm.store %c, %res : i64, !llvm.ptr
545545
```
546546

547547
Note that simple conversion to `alloca` may not be sufficient if the code has

0 commit comments

Comments
 (0)