search for: assumes

...e? e.g., if we proved a >= 0 and that condition is used in assume(a >= 0 || b >= 0), should we keep (a >= 0) in case later passes use them? If yes, we would probably have to recursively traverse def-use chains. If no, some assumption is again lost after instcombine. 2) what if the kept assumes are not leveraged later at all? These assumes bump up values' refcounts and could potentially hurt optimizations. This looks like a problem for adding @llvm.assume in general. Maybe users should be aware of these trade-offs when adding __builtin_assumes in their source code. Thoughts? Thanks,...

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

...ternal functions that have a single use, it is really not > > hard to make the connection. > > It’s certainly not a problem *in theory*. *In theory* every > intraprocedural analysis can be taught to go interprocedural > into a predicate. We might have different expectations how assumes are used or where our analyses/transformation are heading. Not every pass needs to look at assumes at the end of the day. Most information that we use can already, or should be described through an attribute and we have a working way to deduce those interprocedurally. The future, I hope, is dominat...

...oc was eliminated under assumption of success, the if test becomes dead code and we can assume the malloc succeeded. Perhaps the trouble is that your statement, "If LLVM 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 circu...

...odik's extended ssa: http://homepages.dcc.ufmg.br/~fernando/classes/dcc888/ementa/slides/RangeAnalysis.pdf You would at least see that the load result is used by an assume, and could go look at that assume and so something with it. Currently, it's a few steps away. In the current scheme, assumes just float in air, and so it can be hard to see what their effects touch :) On Fri, Jun 10, 2016 at 2:00 PM, Josh Klontz via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for the lead Kevin. Unfortunately when I updated to ToT the problem > persists. Will put together a mini...

...r/~fernando/classes/dcc888/ementa/slides/RangeAnalysis.pdf >> >> You would at least see that the load result is used by an assume, and >> could go look at that assume and so something with it. Currently, it's a >> few steps away. >> >> In the current scheme, assumes just float in air, and so it can be hard >> to see what their effects touch >> :) >> >> >> On Fri, Jun 10, 2016 at 2:00 PM, Josh Klontz via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Thanks for the lead Kevin. Unfortunately when...

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

...y nothing, because of the above. > > > Sanjoy’s argument is faulty, if it were true we would also find our > handling of “assert” to be unacceptable > > but this is not the case, no one is arguing that we need to re-design > “assert”. > Asserts occur much more often than assumes, it may or may not be sensible to handle them the same way. I would argue it is sensible, but it's also reasonable to argue it is not. I would also argue our current way of propagating information for if-then conditions is in fact, quite crappy. Only a small number of passes know how to do it,...

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