[llvm-dev] memcmp code fragment

[Flamedoge via llvm-dev]

I would do this, but might require heroic effort to recognize it. legality
is already questionable allowing full array access (even if memcmp is
lowered to conditional early exit just like original code). I don't know if
you can just turn original code into memcmp based on
http://en.cppreference.com/w/c/string/byte/memcmp

auto a = memcmp(&block[i1], block[i2], 14);
if (a == 0)
  return <unshown above>;
else
  return a > 0;

Kevin


On Mon, May 29, 2017 at 9:12 PM, Nemanja Ivanovic via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/47ca7bda/attachment-0001.html>