On Fri, May 19, 2017 at 4:32 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote:> i think you'd have to write some idiom recognizer here. The ones we have > won't do it. > > I guess my other question would be how commonly this happens. If it's common > and matters a lot, awesome. > I wouldn't do it just to fix SPEC :P > > (people who care about bzip2 speed probably use any of the faster bzip2 > impls :P) >Danny, do you know of forks of bzip2 that are more efficient than bzip.org? I haven't seen one. Sirish is going to send a patch to Julian Seward and try to get the change in a new release of bzip2, and from there we may need to ask the AOSP folks to update bzip2. AOSP has the last released bzip2 from Sept 2010. For SPEC benchmarketing, doing the right thing wouldn't help. Maybe we should put this idiom and others under a -fspec flag ;-) Sebastian
On Wed, May 24, 2017 at 8:09 AM, Sebastian Pop <sebpop.llvm at gmail.com> wrote:> On Fri, May 19, 2017 at 4:32 PM, Daniel Berlin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > i think you'd have to write some idiom recognizer here. The ones we have > > won't do it. > > > > I guess my other question would be how commonly this happens. If it's > common > > and matters a lot, awesome. > > I wouldn't do it just to fix SPEC :P > > > > (people who care about bzip2 speed probably use any of the faster bzip2 > > impls :P) > > > > Danny, do you know of forks of bzip2 that are more efficient than bzip.org > ? > I haven't seen one. >They aren't forks so much as replacements. An example: lbzip2 I know that there are a number of bzip2 impls that use faster versions of the block sorting algorithm (or alternatives) etc.> Sirish is going to send a patch to Julian Seward and try to get the change > in a new release of bzip2, and from there we may need to ask the AOSP > folks to update bzip2. AOSP has the last released bzip2 from Sept 2010. > > For SPEC benchmarketing, doing the right thing wouldn't help. > Maybe we should put this idiom and others under a -fspec flag ;-) > > Sebastian >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170524/61c7f116/attachment.html>
The bzip2 (and how common this pattern is) discussion aside, I'm wondering why this transform is actually correct. For example, in any of the blocks above, if `c2 > c1` the function will return 0 - which is clearly different from what memcmp does. Or am I just missing something super obvious when reading the code. On Thu, May 25, 2017 at 7:04 AM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Wed, May 24, 2017 at 8:09 AM, Sebastian Pop <sebpop.llvm at gmail.com> > wrote: > >> On Fri, May 19, 2017 at 4:32 PM, Daniel Berlin via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > i think you'd have to write some idiom recognizer here. The ones we have >> > won't do it. >> > >> > I guess my other question would be how commonly this happens. If it's >> common >> > and matters a lot, awesome. >> > I wouldn't do it just to fix SPEC :P >> > >> > (people who care about bzip2 speed probably use any of the faster bzip2 >> > impls :P) >> > >> >> Danny, do you know of forks of bzip2 that are more efficient than >> bzip.org? >> I haven't seen one. >> > > They aren't forks so much as replacements. > > An example: lbzip2 > > I know that there are a number of bzip2 impls that use faster versions of > the block sorting algorithm (or alternatives) etc. > > >> Sirish is going to send a patch to Julian Seward and try to get the change >> in a new release of bzip2, and from there we may need to ask the AOSP >> folks to update bzip2. AOSP has the last released bzip2 from Sept 2010. >> >> For SPEC benchmarketing, doing the right thing wouldn't help. >> Maybe we should put this idiom and others under a -fspec flag ;-) >> >> Sebastian >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/10d12010/attachment.html>