Support opaque pointers #102
Comments
|
Hah, I just learned that LLVM also has an |
|
To echo similar sentiments as in GaloisInc/llvm-pretty-bc-parser#177 (comment), I've discovered that adding support the opaque In particular, I've recently discovered that the way that This convention of using a pointer type instead of a function type in I will need to adjust this code as well. I'll open a patch for this. There may be more instructions that need similar adjustments, but I haven't done a thorough audit of all pointer-aware instructions yet. |
This adds basic support for representing and pretty-printing opaque `ptr` types, which were introduced in LLVM 13 as part of a longer-term plan to stop using non-opaque pointer types (e.g., `i8*`). See https://llvm.org/docs/OpaquePointers.html for further details. The next step in `llvm-pretty` is to make sure that all of the instructions that involve pointers in some way (e.g., `call`) have all the information that they need to work with opaque pointers. I will be addressing this in subsequent commits. This is one step towards #102.
Previously, the code in `ppCallSym` assumed that the function type stored in a `call` instruction was a pointer type, but this should actually be a raw function type. See the discussion at GaloisInc/llvm-pretty-bc-parser#189 (comment) for more on this. We now assume the convention of raw function types in `call` instructions, as well as the related `callbr` and `invoke` instructions. This addresses one part of #102.
This adds basic support for representing and pretty-printing opaque `ptr` types, which were introduced in LLVM 13 as part of a longer-term plan to stop using non-opaque pointer types (e.g., `i8*`). See https://llvm.org/docs/OpaquePointers.html for further details. The next step in `llvm-pretty` is to make sure that all of the instructions that involve pointers in some way (e.g., `call`) have all the information that they need to work with opaque pointers. I will be addressing this in subsequent commits. This is one step towards #102.
Previously, the code in `ppCallSym` assumed that the function type stored in a `call` instruction was a pointer type, but this should actually be a raw function type. See the discussion at GaloisInc/llvm-pretty-bc-parser#189 (comment) for more on this. We now assume the convention of raw function types in `call` instructions, as well as the related `callbr` and `invoke` instructions. This addresses one part of #102.
|
I did a slightly more thorough audit of
|
|
Another issue that I ran into in GaloisInc/llvm-pretty-bc-parser#177 (comment) was needing to compare types modulo pointer opaqueness. This is because many parts of eqTypeModuloOpaquePtrs :: Eq ident => Type' ident -> Type' ident -> Bool
cmpTypeModuloOpaquePtrs :: Ord ident => Type' ident -> Type' ident -> OrderingThere's nothing parser-specific about these functions, however, so I wonder if we should put these in Another challenge is that LLVM itself does not allow mixing opaque and non-opaque pointers in a single file, so if you try to use fixupOpaquePtrs :: forall a. Data a => a -> aPerhaps this is something that |
Previously, the code for pretty-printing `callbr` instructins was inspecting a pointer's pointee type, which won't work for opaque pointers. Thankfully, the fix is simple: just use the return type that is stored separately in the `CallBr` data constructor. See #102.
With opaque pointers, one cannot tell what the type being loaded is by inspecting the pointer in the `load` instruction. As a result, we now store the load type separately in the `Load` instruction so that it can be determined regardless of whether opaque pointers are used or not. See #102.
With opaque pointers, one cannot tell what the basis type for a `getelementptr` instruction (or constant expression) is by inspecting the parent pointer. As a result, we now store the basis type separately in `GEP`/`ConstGEP` so that it can be determined regardless of whether opaque pointers are used or not. See #102.
With opaque pointers, one cannot tell what the type being loaded is by inspecting the pointer in the `load` instruction. As a result, we now store the load type separately in the `Load` instruction so that it can be determined regardless of whether opaque pointers are used or not. See #102.
With opaque pointers, one cannot tell what the basis type for a `getelementptr` instruction (or constant expression) is by inspecting the parent pointer. As a result, we now store the basis type separately in `GEP`/`ConstGEP` so that it can be determined regardless of whether opaque pointers are used or not. Because this requires making a backwards-incompatible change to `ConstGEP`, I took the opportunity to include the parent pointer value as a distinguished field in `ConstGEP`. The `GEP` data constructor already does this, and it seems oddly asymmetric to not have `ConstGEP` do the same, especially since LLVM requires it to be present. See #102.
With opaque pointers, one cannot tell what the basis type for a `getelementptr` instruction (or constant expression) is by inspecting the parent pointer. As a result, we now store the basis type separately in `GEP`/`ConstGEP` so that it can be determined regardless of whether opaque pointers are used or not. This also requires tweaking the types of the `resolveGepFull` and `resolveGep` functions to make the basis type separate from the parent pointer type. Because this requires making a backwards-incompatible change to `ConstGEP`, I took the opportunity to include the parent pointer value as a distinguished field in `ConstGEP`. The `GEP` data constructor already does this, and it seems oddly asymmetric to not have `ConstGEP` do the same, especially since LLVM requires it to be present. See #102.
This patch implements `eqTypeModuloOpaquePtrs` and `cmpTypeModuloOpaquePtrs` functions, which provide coarser notions of type equality and comparison that do not distinguish between `PtrTo` and `PtrOpaque`, unlike the `Eq` and `Ord` instances for `Type`. This is useful to support code in which `PtrTo` and `PtrOpaque` exist in the same file. See #102.
…ointers This is useful for ensuring that pretty-printing an `llvm-pretty` AST produces something that will be accepted by `llvm-as`, which unlike `llvm-pretty`, does _not_ support mixing opaque and non-opaque pointers. See #102.
Previously, the code for pretty-printing `callbr` instructins was inspecting a pointer's pointee type, which won't work for opaque pointers. Thankfully, the fix is simple: just use the return type that is stored separately in the `CallBr` data constructor. See #102.
With opaque pointers, one cannot tell what the type being loaded is by inspecting the pointer in the `load` instruction. As a result, we now store the load type separately in the `Load` instruction so that it can be determined regardless of whether opaque pointers are used or not. See #102.
With opaque pointers, one cannot tell what the basis type for a `getelementptr` instruction (or constant expression) is by inspecting the parent pointer. As a result, we now store the basis type separately in `GEP`/`ConstGEP` so that it can be determined regardless of whether opaque pointers are used or not. This also requires tweaking the types of the `resolveGepFull` and `resolveGep` functions to make the basis type separate from the parent pointer type. Because this requires making a backwards-incompatible change to `ConstGEP`, I took the opportunity to include the parent pointer value as a distinguished field in `ConstGEP`. The `GEP` data constructor already does this, and it seems oddly asymmetric to not have `ConstGEP` do the same, especially since LLVM requires it to be present. See #102.
This patch implements `eqTypeModuloOpaquePtrs` and `cmpTypeModuloOpaquePtrs` functions, which provide coarser notions of type equality and comparison that do not distinguish between `PtrTo` and `PtrOpaque`, unlike the `Eq` and `Ord` instances for `Type`. This is useful to support code in which `PtrTo` and `PtrOpaque` exist in the same file. See #102.
…ointers This is useful for ensuring that pretty-printing an `llvm-pretty` AST produces something that will be accepted by `llvm-as`, which unlike `llvm-pretty`, does _not_ support mixing opaque and non-opaque pointers. See #102.
This patch implements `eqTypeModuloOpaquePtrs` and `cmpTypeModuloOpaquePtrs` functions, which provide coarser notions of type equality and comparison that do not distinguish between `PtrTo` and `PtrOpaque`, unlike the `Eq` and `Ord` instances for `Type`. This is useful to support code in which `PtrTo` and `PtrOpaque` exist in the same file. See #102.
…ointers This is useful for ensuring that pretty-printing an `llvm-pretty` AST produces something that will be accepted by `llvm-as`, which unlike `llvm-pretty`, does _not_ support mixing opaque and non-opaque pointers. See #102.
Previously, the code for pretty-printing `callbr` instructins was inspecting a pointer's pointee type, which won't work for opaque pointers. Thankfully, the fix is simple: just use the return type that is stored separately in the `CallBr` data constructor. See #102.
With opaque pointers, one cannot tell what the type being loaded is by inspecting the pointer in the `load` instruction. As a result, we now store the load type separately in the `Load` instruction so that it can be determined regardless of whether opaque pointers are used or not. See #102.
With opaque pointers, one cannot tell what the basis type for a `getelementptr` instruction (or constant expression) is by inspecting the parent pointer. As a result, we now store the basis type separately in `GEP`/`ConstGEP` so that it can be determined regardless of whether opaque pointers are used or not. This also requires tweaking the types of the `resolveGepFull` and `resolveGep` functions to make the basis type separate from the parent pointer type. Because this requires making a backwards-incompatible change to `ConstGEP`, I took the opportunity to include the parent pointer value as a distinguished field in `ConstGEP`. The `GEP` data constructor already does this, and it seems oddly asymmetric to not have `ConstGEP` do the same, especially since LLVM requires it to be present. See #102.
This patch implements `eqTypeModuloOpaquePtrs` and `cmpTypeModuloOpaquePtrs` functions, which provide coarser notions of type equality and comparison that do not distinguish between `PtrTo` and `PtrOpaque`, unlike the `Eq` and `Ord` instances for `Type`. This is useful to support code in which `PtrTo` and `PtrOpaque` exist in the same file. See #102.
…ointers This is useful for ensuring that pretty-printing an `llvm-pretty` AST produces something that will be accepted by `llvm-as`, which unlike `llvm-pretty`, does _not_ support mixing opaque and non-opaque pointers. See #102.
LLVM is in the process of migrating all of its pointer types from
i8*,i32*, etc. to an opaqueptrtype, as described here. LLVM 13 takes an important step in that direction, as it is the first LLVM release to includeptrin the LLVM AST. See llvm/llvm-project@2155dc5.We should support opaque pointers in the LLVM AST and pretty-printer. In particular, we will have to either add a new
OpaquePointerconstructor that doesn't take a pointee type as an argument, or makePtrTotake aMaybe.See also: GaloisInc/llvm-pretty-bc-parser#177
The text was updated successfully, but these errors were encountered: