[llvm-dev] memcmp code fragment

[Nemanja Ivanovic via llvm-dev]

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>