[llvm] [CodeGen] Make LoadExtActions address-space aware (PR #162407)

Derek Schuff via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 8 11:38:00 PDT 2025


dschuff wrote:

So if I'm understanding you, then setLoadExtAction basically becomes overloaded rather than having a default argument, with the existing overload getting the existing behavior and the addrspace version overriding it. That also seems pretty reasonable, although it does make the API a bit more complex. 

Let's also not completely throw out the solution of just changing the behavior without the default parameter. This has the advantage that it's the simplest API. There is the up-front cost to change the backends (this can maybe be partly automated; but it also includes churn imposed on downstream backend maintainers, which needn't be an automatic dealbreaker but also isn't nothing). it also has the cost that future uses will have to include the argument even if they don't care about address spaces, but this doesn't seem so bad because the behavior is otherwise the same so this shouldn't be hard to figure out.

Going with the default argument means less churn, but as you pointed out it's a silent change in behavior. (I started the CI for the PR, so we'll see which other targets might need updating in this version).

Churn is a one-time cost, but additional API complexity is an ongoing cost (and in that model maybe you'd consider a silent behavior change to be a one-time cost but which is spread out over time as people discover it, so probably worse than an equivalent all-at-once change). Of course you can argue all day about how bad extra API complexity is.

I wonder, is the additional complexity from the overload version buying us anything beyond avoiding one-time churn? Like, are there any targets that could use both versions together, or would they all just use one or the other?

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


More information about the llvm-commits mailing list