search for: assumably

Hi, I have some WIP that leverages @llvm.assume in some optimization passes other than InstCombine. However, it doesn't work yet because InstCombine removes @llvm.assume calls that are useful for later optimizations. For example, given define i32 @foo(i32 %a, i32 %b) { %sum = add i32 %a, %b %1 = icmp sge i32 %sum, 0 call void @llvm.assume(i1 %1) ret i32 %sum } "opt

Abstract: It is often hard or impossible to encode complex, e.g., non-boolean, information in an `llvm.assume(i1)`. This RFC describes various problems we have right now and provides alternative design ideas. Some Existing Problems: A) The boolean requirement. The current `llvm.assume(i1)` expects a boolean that is known to hold true at runtime (once the `llvm.assume` call is reached).

On 12/18, John McCall wrote: > On 16 Dec 2019, at 18:16, Doerfert, Johannes via llvm-dev wrote: > > Abstract: > > > > It is often hard or impossible to encode complex, e.g., non-boolean, > > information in an `llvm.assume(i1)`. This RFC describes various problems > > we have right now and provides alternative design ideas. > > > > > > > >

Josh Coalson wrote: > --- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > > > Hi all, > > > > Is seeking working for OggFlac files? I keep on getting a > > FLAC__STREAM_DECODER_SEEK_ERROR. > > yes, it should work fine. in flac/src/test_seeking/main.c there > is an example usage of FLAC__stream_decoder_seek_absolute(). you > could try

Hi John, Is it correct to assume that you are in favor of - changing llvm.assume to be more expressive - operand bundle uses, especially w/o outlining - outlining, if we can show it plays well with transformations, e.g. the binding to the code is "weak" I inlined more comments below. On 12/18, John McCall wrote: > On 18 Dec 2019, at 11:28, Doerfert, Johannes wrote: >

On Wednesday 30 April 2008 21:21, Chris Lattner wrote: > If LLVM is able to eliminate all users of the malloc assuming the > malloc succeeded (as in this case), then it is safe to assume the malloc > returned success. Ah, I missed this bit. I didn't see that the result of malloc was not used outside the if test. But is the if test considered a "use?" If so, it's a

Yeah, that change is completely unrelated, that is about correctness, this is about optimization. I'm working on a proposal to just fix assume at some point to deal with the former issue. The problem with this testcase is that all the ways assume is propagate expect the variable in the assume to later be used. <This is the main way assume constants are propagated> bool

Maybe. It may not fix it directly because you never use %1 or %2 again. I haven't looked to see how good the lookup is. On Fri, Jun 10, 2016, 3:45 PM Josh Klontz <josh.klontz at gmail.com> wrote: > Thanks Daniel, with that knowledge I think I can at least work around the > issue in my frontend. > > Ignoring GVN for a second though, and just looking at Early CSE, it seems

On Wed, 30 Apr 2008, Ryan M. Lefever wrote: > Consider the following c code: > #include <stdlib.h> > int main(int argc, char** argv){ > if(malloc(sizeof(int)) == NULL){ return 0; } > else{ return 1; } > } > > > When I compile it with -O3, it produces the following bytecode: > > define i32 @main(i32 %argc, i8** %argv) { > entry: > ret i32 1

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

On Thu, 2008-05-01 at 12:00 -0500, David Greene wrote: > On Wednesday 30 April 2008 21:21, Chris Lattner wrote: > > > If LLVM is able to eliminate all users of the malloc assuming the > > malloc succeeded (as in this case), then it is safe to assume the malloc > > returned success. > > Ah, I missed this bit. I didn't see that the result of malloc was not used

As of llvm 3.8, the early CSE pass seems to remove llvm.assume intrinsics. Is this the expected behavior? I've attached as small-ish example of this happening in my production code. $ opt -early-cse before-early-cse.ll -S > after-early-cse.ll Note the use of the assume intrinsic indicating that the loaded value %channels equals 3. In a later pass I replace the load instruction with

Daniel, Well then my next (dumb?) question is why aren’t we using source level assert information For optimization ? --Peter Lawrence. From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Friday, June 10, 2016 5:39 PM To: Lawrence, Peter <c_plawre at qca.qualcomm.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume On Fri, Jun

My (dumb?) question would be: why is llvm.assume being handled any differently than llvm.assert ? Other than one trapping and one not-trapping, they should be identical, in both cases they are giving The optimizers information, and that shouldn't be any different from being inside an "if" statement with the same condition ? --Peter Lawrence. -------------- next part --------------

On Tue, Jun 14, 2016 at 10:36 AM, Lawrence, Peter <c_plawre at qca.qualcomm.com > wrote: > Daniel, > > What am I missing in the following chain of logic: > > > > As far as constant-prop, value-prop, range-prop, and general > property-propagation, > > > > 1. the compiler/optimizer **has** to get it right for if-then-else and > while-do or

--- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > Josh Coalson wrote: > > > --- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > > > > > Hi all, > > > > > > Is seeking working for OggFlac files? I keep on getting a > > > FLAC__STREAM_DECODER_SEEK_ERROR. > > > > yes, it should work fine. in

On Thursday 01 May 2008 19:14, Jonathan S. Shapiro wrote: > On Thu, 2008-05-01 at 12:00 -0500, David Greene wrote: > > On Wednesday 30 April 2008 21:21, Chris Lattner wrote: > > > > > If LLVM is able to eliminate all users of the malloc assuming the > > > malloc succeeded (as in this case), then it is safe to assume the malloc > > > returned success. >

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

Hi all, Is seeking working for OggFlac files? I keep on getting a FLAC__STREAM_DECODER_SEEK_ERROR. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Why do they protest against France for making it illegal to wear hijabs, but not against Saudi Arabia for making it illegal not to

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