[llvm] [IR] Make dead_on_return attribute sized (PR #171712)

[Nikita Popov via llvm-commits]

nikic wrote:

> > Can you share how the DSE changes will look like?
> 
> I have a rough prototype in [boomanaiden154 at c0972fb](https://github.com/boomanaiden154/llvm-project/commit/c0972fba7c300af3d5794c3ab2049d08970d6d0c). I still need to double check some things (mostly that this correctly handles stores that straddle the boundaries and making sure I'm interpreting the API return values correctly in the case of non-constant offsets) and clean it up.
> 
> > It looks like we currently fail to use dead_on_return inside isNotVisibleOnUnwind(), but that would also have to check the range with this approach. Possibly dead_on_unwind also needs the argument?
> 
> It would only need to have the range check if we make DSE understand that `dead_on_return` implies `dead_on_unwind` if I am understanding things correctly. I think it should be reasonable to implement that in DSE without needing a sized `dead_on_unwind`. I haven't seen any motivating examples for a sized `dead_on_unwind`, but we also compile almost everything with `-fno-exceptions`, so I wouldn't be the one to see many.

IIRC DSE implicitly relies on the store also being dead on unwind if it's dead on return. Though I guess for that it's not strictly necessary to change dead_on_unwind, as long as we specify that dead on return only implies dead on unwind for the same range.

> > One thing I'm wondering is whether it makes sense to make the argument optional, to avoid the need to prove that the access is within specific bounds in the cases where it's not relevant (e.g. the original motivation for dead_on_return, which is byval-like arguments).
> 
> That's definitely an option. I felt like the DSE changes did not look too expensive (just walking the use-def chain of the store pointer to calculate the offset from the original object), but I haven't collected any compile time numbers yet. This does pessimize the elimination of stores that have a variable offset from the base object, but I don't think that is the common case with either byval-like arguments or a destructor's `this` pointer.

The variable offset case is the one I had in mind here.



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