search for: assuming

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. > > > > > > > >

...re is a bug that your stream is triggering. Ok, running the command: src/test_seeking/test_seeking flac_char.ogg resulted in: +++ seek test: FLAC__StreamDecoder (Ogg FLAC, read_mode=0) file's total_samples is 0 Begin seek barrage, count=0 #0:seek(0)... seek failed, assuming it was past EOF... OK #1:seek(1)... seek failed, assuming it was past EOF... OK #2:seek(2)... seek failed, assuming it was past EOF... OK #3:seek(3)... seek failed, assuming it was past EOF... OK #4:seek(4)... seek failed, assuming it was past EOF... OK #5:seek(5)... seek failed...

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 use in the context of s...

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

...hould be possible for malloc to return NULL, if > it can not allocate more space. In fact, some programs should be able > to gracefully handle such situations. LLVM should not (and does not, afaik) assume the malloc succeeds in general. 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. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...e body of the assert might not even be parsable code when NDEBUG is defined. It might, for example, refer to variables that are only declared when NDEBUG is not defined. 2. Even saying that we'd get around this by ignoring parsing errors within the assert when NDEBUG is defined, but otherwise assuming the result is not desirable. There are large bodies of code which do this; assert(i > 5); if (i <= 5) throw a_strange_error(); so that, in production builds, the program does not crash, but instead unwinds. There are all sorts of reasons we can use to argue this is a bad coding practice...

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 > outside the if test. > > But is the if test considered a "use?" If so,...

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

...unning the command: > > src/test_seeking/test_seeking flac_char.ogg > > resulted in: > > +++ seek test: FLAC__StreamDecoder (Ogg FLAC, read_mode=0) > > file's total_samples is 0 > Begin seek barrage, count=0 > #0:seek(0)... seek failed, assuming it was past EOF... OK > #1:seek(1)... seek failed, assuming it was past EOF... OK > #2:seek(2)... seek failed, assuming it was past EOF... OK > #3:seek(3)... seek failed, assuming it was past EOF... OK > #4:seek(4)... seek failed, assuming it was past EOF... OK >...

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. > > > > 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 co...

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