[llvm-dev] RFC: Supported Optimizations attribute

[Sanjoy Das via llvm-dev]

On Tue, Dec 4, 2018 at 11:24 AM John McCall <jmccall at apple.com> wrote:
>> In other words, certain things are UB in functions tagged with
>> supported_optimizations that are not UB otherwise? This breaks code
>> hoisting transformations right? I.e.
>> isSafeToSpeculativelyExecute(Inst) will have to return false if Inst
>> is in a function with a non-empty supported_optimizations?
>>
> Good question. I would consider that to be an unacceptable intrusion:
> intraprocedural transforms should never have to be aware of
> supported_optimizations (unless they're implementing a good-faith
> optimization, of course) and interprocedural transforms should only have
> to be aware of supported_optimizations in the narrow sense outlined
> by Piotr. If something about the optimization's representation in IR
> is unsafe to speculate, it should be made impossible to speculate for
> standard semantic/structural reasons, like having apparently arbitrary
> side-effects.
>
> I think the right way to formalize this is to say that, while the
> good-faith optimization may impose additional UB rules on the function,
> it must guarantee that transforms that are well-behaved as described
> above --- i.e. that preserve standard structure and semantics and which,
> if interprocedural, appropriately honor supported_optimizations --- will
> never introduce new UB.

I see.  Would it be correct to say that a good faith optimization `O`
assumes that a certain construct(s), `FOO`, does not occur in the
*trace* of the program within the function tagged with
supported_optimizations={O}?  Also `FOO` has to be side effecting so
LLVM cannot speculate it into existence (e.g. `FOO` can't be
"getelementptr with a certain property").

-- Sanjoy