search for: assum

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

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). However,...

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. > > > > > > > > Some Existing Problems: > > > > A) The boolean requirement. > > The current `llvm.assume(i1)` expects a boolean that is known to...

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

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

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

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 GVN::processAssumeIntrinsic(IntrinsicInst *Inst) { ... /...

...e. > > v/r, > Josh > > On Fri, Jun 10, 2016 at 4:23 PM, Daniel Berlin <dberlin at dberlin.org> > wrote: > >> 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> >&...

...rgc, i8** %argv) { > entry: > ret i32 1 > } > > Is this an error? It should 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/

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

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

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

...g 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 10, 2016 at 5:34 PM, Lawrence, Peter via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: My (dumb?) question would be: why is llvm.assume being handled any differently than llvm.assert ? There is no llvm.assert intrinsic, so i'm not...

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

...over J > Only certain parts of the compiler know how to do this. This is precisely one of the reasons i'm proposing we've gotten it wrong. > > > 2. “assert” takes advantage of this by being translated into if-then logic > early on in the compilation > > > > 3. “assume” should also take advantage of this the same way. (generate a > call to “pseudoabort” which > > At some late stage gets deleted) > This would fix precisely nothing, because of the above. > > > Sanjoy’s argument is faulty, if it were true we would also find our > handlin...

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

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

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 one but not the others) Then we aren’t doing a good job of engineering, IE we should be able to get “assume” to work for free...