[SIL] Bridge findPointerEscape() and fix OnoneSimplifyable

[atrick]

Do not bridge the hasPointerEscape flag until it is implemented.

[atrick]

@swift-ci test

[atrick]

@swift-ci test

[atrick]

@swift-ci smoke test

[atrick]

@swift-ci smoke test linux

[meg-gupta]

LGTM

[eeckstein]

basically lgtm.
Just a few minor comments

[eeckstein]

Can you copy the comment from the C++ function?

nitpick: I would find it a bit more self describing if this is a top-level function findPointerEscape(inLiferangeOf: Value) -> Bool

[atrick]

Value should have a hasPointerEscape method in primary declaration, not an extension. It is an important property of the type that changes the semantics. Anyone who needs to maintain the OSSA correctness of the Value needs to first check this. Of course, calling that method should not require a def-use traversal, but that is a hack until we have flags.

But since you mention what goes in an extension, I don't think any of the utilities in OptUtils should extend the basic SIL types: Value and Instruction. They are algorithms specific to some task. They don't meet any of the requirements for extending a type. They are not fundamental to the type, they don't affect how anyone else would use the type, and they don't require any internal knowledge of the type.

isTrivial is a great example where we need clarity. When written as an extension on Value, it will be confused with whether the value has trivial ownership (value.type.isTrivial). But this implementation is different, and its meaning may change after unrelated transformations.

[atrick]

@swift-ci smoke test