search for: assumed

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

...well. Take for example function attributes and inlining. Since we know they hold for the entire function and not only when it is entered we could encode the information over the entire range of the inlined code. Some Site Notes: - It seems of little use that we interleave the code for the assumed expression with the user code. Having the `llvm.assume` allows us to tie information to a program point, beyond that we just clutter the function with instructions that we later remove anyway. - Reconstructing information from the pattern of instructions that feed into the `llvm.assume` is...

...> they hold for the entire function and not only when it is entered we > > could encode the information over the entire range of the inlined > > code. > > > > > > Some Site Notes: > > > > - It seems of little use that we interleave the code for the assumed > > expression with the user code. Having the `llvm.assume` allows us to > > tie information to a program point, beyond that we just clutter the > > function with instructions that we later remove anyway. > > > > - Reconstructing information from the pattern of i...

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

...en it is entered we > >>> could encode the information over the entire range of the inlined > >>> code. > >>> > >>> > >>> Some Site Notes: > >>> > >>> - It seems of little use that we interleave the code for the assumed > >>> expression with the user code. Having the `llvm.assume` allows us to > >>> tie information to a program point, beyond that we just clutter the > >>> function with instructions that we later remove anyway. > >>> > >>> - Reconstr...

...is able to eliminate all users of the malloc assuming the malloc succeeded," is ambiguous. Do you mean that LLVM assumes the malloc succeeded and then tries to eliminate all users by making use of that assumption or that it tries to eliminate all users that are in a context where malloc is assumed to have succeeded (for example the "else" of a check for malloc failure)? If the former, it's a circular argument, if the latter, then what about the use in the if test, which is in a context where we don't know whether the malloc succeeded or not? Just trying to get some c...

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