[llvm-dev] [RFC] How to manifest information in LLVM-IR, or, revisiting llvm.assume
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 29 20:58:00 PST 2020
Thanks for working on this. This seems like a good approach which nicely
extends the set of capabilities we have now.
One additional comment, as I agree with everything in your rationale,
> - Reconstructing information from the pattern of instructions that feed
> into the `llvm.assume` is also not optimal, especially since we do
> not need to "optimize" these instructions anyway.
I don't understand what you mean by the reconstructing the pattern from
the instructions not being optimal, but in general, we do need to
optimize the instructions forming the assumption condition. The
expressions might have calls that should be inlined, or as a general
matter, have expressions involving temporaries that need to be
simplified (especially soon as you start allowing expressions that might
have side effects, you'll also have to deal with temporaries that are
materialized to the stack).
There is also the matter of inter-procedural code sinking that will come
up (assuming that we want to, with this mechanism, get rid of the
existing ephemeral-values concept and utility functions). Instructions
in the function containing the assumption, that are only used by the
assumption, we'll want to sink in the outlined assumption function. I
believe you're thinking about addressing this with outlining, but I
think that these are separate issues because the outlining needs to be
done early. Regarding this late-outlining approach:
> A prototype for both operand bundle assumptions and outlined assumptions
> is available herehttps://reviews.llvm.org/D71692. Note that most code
> is required do to the outlining [see rational in point C) below]. This
> is not as actively purposed for now as the operand bundle use.
I don't see how this can work in the case where you have side effects.
Once you generate the code in the function containing the assume, if
that code has side effects, it's can't be later deleted and moved into
the assumption. One might make an argument that we can do this for
non-volatile loads (because if the load is used only by the assumption
it will be removed anyway), but for stores and other things that will
appear from general expressions, it won't be sound to outline them
later. We can't know if the side effect is supposed to be there or not,
so the outlining needs to happen in the frontend.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev