similar to: [LLVMdev] How best to represent assume statements in LLVM IR?

Hi Philip, > Does anyone have any suggestions on how to best represent an assumption > statement(*) in IR? good question! There have been various attempts, for example Nick tried teaching the optimizers to not prune the branch to unreachable in br %cond, label %assumption_holds, %assumption_doesnt_hold assumption_doesnt_hold: unreachable This then leads to %cond being replaced

On 10/02/2012 12:52 AM, Duncan Sands wrote: > Hi Philip, > >> Does anyone have any suggestions on how to best represent an assumption >> statement(*) in IR? > > good question! There have been various attempts, for example Nick tried > teaching the optimizers to not prune the branch to unreachable in > > br %cond, label %assumption_holds, %assumption_doesnt_hold

On Tue, 02 Oct 2012 14:43:51 -0700 Philip Reames <listmail at philipreames.com> wrote: > On 10/02/2012 12:52 AM, Duncan Sands wrote: > > Hi Philip, > > > >> Does anyone have any suggestions on how to best represent an > >> assumption statement(*) in IR? > > > > good question! There have been various attempts, for example Nick > > tried

On 2008-10-22, at 19:24, Mike Stump wrote: > On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > >> As part of our PHP compiler (phpcompiler.org), it would be great to >> be able to annotate our generated C code with, for example, (var != >> NULL), or (var->type == STRING), and have that information passed >> around (esp interprocedurally at link-time) by the

On Fri, Jun 10, 2016 at 9:58 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Jun 10, 2016, at 7:00 PM, Lawrence, Peter via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Daniel, > My point is this, > > If (cond) ---- optimizer takes advantage of knowing cond == true within > the “then” part > Assert(cond)

Hi all, I've been thinking about this issue as well, since I'm working with a architecture that can do hardware based loops, but only when the loop count is more than some minimal value. To probably use this, we need some way for the code to specify that a loop variable has a minimum value. > Can't you implement __builtin_assume(cond) to codegen to something like: > >

Hal, To simplify this discussion, lets first just focus on code without asserts and assumes, I don’t follow your logic, you seem to be implying we don’t optimize property-propagation through “if-then” and “while-do” well ? --Peter. From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Tuesday, June 14, 2016 11:12 AM To: Lawrence, Peter <c_plawre at qca.qualcomm.com> Cc: llvm-dev

Dave, Dead code elimination is generally done in a pass called dead code elimination, Can you give concrete examples why the same would not be true for UB code elimination ? Yes, speculatively hoisting code requires it to be UB-free, but that has nothing to do with UBCE deleting entire blocks of code because of the existence of UB. The former requires an analysis proving UB-absense, the

On Mon, Jul 31, 2017 at 7:40 AM Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > Dave, > Dead code elimination is generally done in a pass called dead > code elimination, > Can you give concrete examples why the same would not be true for UB code > elimination ? > I haven't actually looked at how optimizations on the basis of the code being UB-free

What he said :) It also, representationally, has a related issue our current assume does in terms of figuring out the set of assumptions applied. Given an instruction, in extended SSA, because " assume" produces a value used by things, it's trivial to find the chain of assumptions you can use for it. In a straight control flow representation, it requires finding which side of the

Daniel, My point is this, If (cond) ---- optimizer takes advantage of knowing cond == true within the “then” part Assert(cond) ---- optimizer takes advantage of knowing cond == true for the rest of the scope Assume(cond) ---- optimizer takes advantage of knowing cond == true for the rest of the scope If we aren’t implementing these in a consistent manner (like using an intrinsic for

> On Jul 21, 2017, at 10:55 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2017-07-21 22:44 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>>: > Mehdi, > Hal’s transformation only kicks in in the *presence* of UB > > No, sorry I entirely disagree with this assertion: I believe we

This is a proposal to add guard intrinsics to LLVM. Couple of glossary items: when I say "interpreter" I mean "the most conservative tier in the compilation stack" which can be an actual interpreter, a "splat compiler" or even a regular JIT that doesn't make optimistic assumptions. By "bailing out to the interpreter" I mean "side exit" as

David, -fsanitize=undefined sounds great, but is not quite what I want. I recently ran into a problem with "CodeGen/MachineSink.cpp” [*], for a target that has to expand Select into control flow. The original IR had two select in a row that were based on the same condition, so the CMP that sets the FLAGS reg in the second select was MCSE’ed to the earlier CMP in the first

On Oct 22, 2008, at 10:45 PM, Duncan Sands wrote: >> Can't you implement __builtin_assume(cond) to codegen to something >> like: >> >> %cond = i1 ... >> br i1 %cond, label %always, label %never >> never: >> unreachable >> always: > > The code generators will remove the branch to %never. > I already tried this :) What would work is

Hi, Simple description of the problem below. I have code coming into pruneEH as follows fn a { entry: call fn b ... for_cond: %i = phi [1, entry] [%x, for_body] cmp $i with someval cond-br for_body or for_exit for_body: ... $x = $i + 1 branch for_cond for_exit ... } PruneEH determines that the call to fn-b won't return. The code is modified thus. fn a { entry: call fn b unreachable insn

Dave, The way I see it there should be just one pass that implements deleting UB (maybe it would come to be called UBCE), and that one pass should have a command line option simply for the reason than all passes should have one. Peter Lawrence. > On Jul 26, 2017, at 10:02 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Jul 26, 2017 at 9:23 PM

> > %cond = i1 ... > > br i1 %cond, label %always, label %never > > never: > > call void @llvm.abort() > > unreachable > > > > At codegen time @llvm.abort() can be lowered to > > nothing at all. I'm not saying that this is my > > favorite solution, but it is simple. > > How is this different than just branching to unreachable?

Would it be wrong to generate the llvm.assume IR suggested below? in GVN? Given more info via the AssumptionCache, InstCombine can then do more optimizing. On Thu, Dec 4, 2014 at 12:10 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 12/04/2014 02:19 AM, Lars Rasmusson SICS wrote: > > Hi, > > I'm compiling a large code base that uses tagged data, with

Mehdi, Hal’s transformation only kicks in in the *presence* of UB, and it does not matter how that UB got there, whether by function inlining or without function inlining. The problem with Hal’s argument is that the compiler does not have a built in ouija board with which it can conjure up the spirit of the author of the source code and find out if the UB was intentional with the