[Mlir-commits] [mlir] [MLIR][LLVM] Support dso_local_equivalent constants (PR #132131)

[Bruno Cardoso Lopes]

bcardosolopes wrote:

> There is a slight issue with constant folding this. Since it produces a FlatSymbolRefAttr like AddressOfOp it currently would be constant folded to an AddressOfOp if I understand correctly (see my comment on the PR).

True, thanks for pointing this out!

> So maybe this is a hint that we should model this using AddressOfOp.

If we go this way, I'm curious if should we do the same in the future for `no_cfi`? How about `ptrauth` and `blockaddress` (they are slightly different but still somewhat similat)?
https://llvm.org/docs/LangRef.html#well-defined-values

> Is LLVM always generating a DSOLocalEquivalent if the symbol references a DSOLocalEquivalent?

Can you elaborate a bit? Not sure I understand what you mean.

My understanding is that `dso_local_equivalent` indeed acts like an operation: it does not appear along side the attributes, but either in (a) computations within constants or (b) after the call result type in calls.

Example, this is valid:
```
declare void @extern_func()
@const = dso_local constant i32 trunc (i64 sub (i64 ptrtoint (ptr dso_local_equivalent @extern_func to i64), i64 ptrtoint (ptr @const to i64)) to i32)
```

This is invalid:

```
declare void dso_local_equivalent @extern_func()
@const = dso_local constant i32 trunc (i64 sub (i64 ptrtoint (ptr @extern_func to i64), i64 ptrtoint (ptr @const to i64)) to i32)
```

> Alternatively, we may have to introduce a DSOLocalSymbolRefAttr or similar so that we can reliable materialize the correct op type. Even then it may make sense to still use AddressOfOp to have one way of referencing a symbol. ... I think I favor computing this property from the IR if this is possible.

Gotcha, let me explore a bit more and see what can be done.

https://github.com/llvm/llvm-project/pull/132131