Llvm.type.checked.load.relative semantics

Development Compiler
1

Hi, I noticed that the semantics of llvm.type.checked.load.relative seem to be a little different from that of llvm.load.relative. It looks like the semantics for llvm.type.checked.load.relative is ptr + offset + *(ptr + offset) whereas the semantics for llvm.load.relative is ptr + *(ptr + offset). That is, the offset for the former is added to the offset address whereas the later has the offset added to the original pointer. Is this intentional?

Asking because it really feels like the checked intrinsic was meant to match the semantics of the non-checked intrinsic, but I think for all cases the checked intrinsic is used (swift being the only use I know of), the calculation just happens to be the same because swift always uses an offset of zero. Likewise, all llvm tests for this intrinsic happen to use an offset of zero.

I will be posting a change to the semantics in upstream LLVM for llvm.type.checked.load.relative to match llvm.load.relative, but wanted to make sure this potentially wouldn't break any swift users who I think were the folks who introduced this checked intrinsic.

2

[llvm] Match llvm.type.checked.load.relative semantics to llvm.load.r… by PiJoules · Pull Request #129583 · llvm/llvm-project · GitHub for the llvm change

3

It is unlikely that anyone is using Swift like this, as using llvm directly would be against best practices and would be highly unstable as well as being difficult to debug. You can try to make a PR or run the workflows for swiftlang/swift to check build health from moving to this new version.

Old Statement
“…while Swift is a LLVM language this is not the place for bringing up LLVM semantics. This seems like it would make more sense as an issue/PR on swiftlang/swift or on llvm/llvm-project .”

4

This is a quite reasonable place to ask a question like this, since it's related to development of the compiler itself (especially if Swift appears to be the only mainstream user of this LLVM intrinsic so far and ).

cc @Arnold and @kubamracek for their insights, since they implemented the original feature and its use in IRGen.