similar to: anyone want to help tune up computeKnownBits()?

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

On the subject of undefined behavior and known bits, as I'm sure some of you are aware, code in ValueTracking.cpp is exploiting poison value rules to get a bit of extra precision in the known bits. These rules fire on examples like the ones below. Do we have a set of rules that clients of known bits need to follow to avoid unsoundness? I remember Nuno and/or David Majnemer saying

> I just noticed: most of the results in this batch seem to be about exploiting `[zs]ext i1` having cost 1 > in order to replace a select of cost 3. > Could you do a run where select has cost 1 and [zs]ext i1 (and trunc to i1) has cost 2 or 3? I tried this (or something quite similar) earlier and it caused Souper to introduce *a lot* of selects. So the problem is that Souper's

We (the folks working on Souper) would appreciate any feedback on these IR-level superoptimizer results: http://blog.regehr.org/extra_files/souper-jul-15.html My impression is that while there's clearly plenty of material in here that doesn't want to get implemented in an opt pass, there are a number of gems hiding in there that are worth implementing. Blog post containing

On Wed, Jul 22, 2015 at 9:27 PM, John Regehr <regehr at cs.utah.edu> wrote: > I just noticed: most of the results in this batch seem to be about >> exploiting `[zs]ext i1` having cost 1 >> in order to replace a select of cost 3. >> Could you do a run where select has cost 1 and [zs]ext i1 (and trunc to >> i1) has cost 2 or 3? >> > > I tried this (or

In the section about poison values, the LLVM language reference manual says: "Values other than phi nodes depend on their operands." This implies that a select instruction's output can be poisoned by its not-selected argument value. If select were poisoned only by its selected argument, we would expect this fact to be mentioned specifically, as it is for phi. Next I'll

On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.

One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,

On 07/22/2015 09:27 PM, John Regehr wrote: >> I just noticed: most of the results in this batch seem to be about >> exploiting `[zs]ext i1` having cost 1 >> in order to replace a select of cost 3. >> Could you do a run where select has cost 1 and [zs]ext i1 (and trunc >> to i1) has cost 2 or 3? > > I tried this (or something quite similar) earlier and it

> Poison is a flawed concept. I proved it was flawed back in 2011 [0] Nice. My colleagues and I will dig through this material and possibly come back with some ideas. We're going to need some sort of semantics for UB in LLVM since otherwise these formal-methods-based tools like Souper and Alive risk not making sense. Thanks, John

I _think_ there is a problem with the license as well: Z3 is MIT, so clang would have to be released with Z3's license. On Tue, 12 Feb 2019, 09:24 Roman Lebedev via cfe-dev <cfe-dev at lists.llvm.org wrote: > On Tue, Feb 12, 2019 at 4:13 PM Paulo Matos via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > > > Hello, > > > > I am trying to run scan-build

I hope there's some useful material in here! http://blog.regehr.org/archives/1192 John

I strongly suspect pointer union and pointer int pair style classes are the source of these... But perhaps I'm wrong On Nov 26, 2014 9:29 AM, "Michael Zolotukhin" <mzolotukhin at apple.com> wrote: > John, > > That’s a great post and really interesting data, thank you! > > On Nov 25, 2014, at 9:58 AM, Reid Kleckner <rnk at google.com> wrote: > >

> Interesting. Do you happen to have some examples laying around? Sorry, no, I'll have to re-run. I felt that the select-heavy results were sort of humorous and clever at first, but then just annoying. > Except for decode-limited situations, in general decreasing the critical path length is more important > than eliminating instructions. The critical path length is a

https://bugzilla.samba.org/show_bug.cgi?id=13953 Bug ID: 13953 Summary: error message instead of --stats informations (in case of vanished files), using rsync 3.1.1 and rsync 3.0.9 Product: rsync Version: 3.1.1 Hardware: x64 OS: Linux Status: NEW Severity: normal Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=2239 Bug ID: 2239 Summary: ssh-keygen cannot handle Linux with 64 char long hostname Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 Component: ssh-keygen

Hello all, I've seen some discussion that InstCombine is "too general" and that llvm should implement a proper graph rewrite mechanism: Link to llvm-dev discussion about this: http://lists.llvm.org/pipermail/llvm-dev/2017-May/113219.html, Link to review where this came up (and I first heard about it): https://reviews.llvm.org/D37195. I wanted to understand what the current issues

Thanks for the response. Should I create a small prototype of equality saturation as an LLVM pass so that there can be some concrete discussion on this? I'd love pointers. Thanks, Siddharth On Wed 6 Sep, 2017, 23:35 John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Equality saturation is very cool work and Ross Tate mentioned to me that > he'd be happy to chat

On 07/23/2015 07:24 AM, John Regehr wrote: >> I guess another way to select interesting transformations could be to >> look for sequences where the >> result uses a "subset" of the input instruction sequence. > > Yeah, I had been noticing those subsets too. It sounds like it's > worth a try doing a run that looks only for those. > > One nice thing

> I guess another way to select interesting transformations could be to look for sequences where the > result uses a "subset" of the input instruction sequence. Yeah, I had been noticing those subsets too. It sounds like it's worth a try doing a run that looks only for those. One nice thing is that if we're just looking for subsets, we will not even give the