[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

Hi, Johannes,

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, 
except this:

> - 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
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

More information about the llvm-dev mailing list