<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<pre>>>On Mon, Dec 07, 2015 at 07:33:29AM +0100, Maciej Adamczyk via llvm-dev wrote:
>><i> Hello.
</i>>><i> My friend's data compressor has a problem. During decompression stage, on
</i>><i>> some corrupted files, it may issue an overlapping memcpy.
</i>>><i> He has two easy solutions for that:
</i>><i>> * switch to memmove
</i>><i>> * add a branch to detect such case
</i>>><i> However, he's not happy with either of them as they slow the decompression
</i>><i>> down to handle a case that will never happen to almost everyone.
</i>>
> While I don't think any of this is really LLVM specific, the second is
> certainly the correct approach if the file format explicitly disallows
> such overlapping ranges. LZMA streams for example are perfectly well
> defined for that case and it even make sense for certain overlapping
> pattern to say "copy 256 Bytes starting from offsets -8". If you
> know that this condition is invalid for well formed input, mark the
> condition as predicted false and the compiler will try to turn it into a branch
> statement that the branch prediction of the CPU can understand.
>
> Joerg
This is not LLVM specific, but this is a place where I can meet people knowledgable about UB.
Initially when I read the description I identified the issue the same way you did. I was wrong, it's a different feature.
Predicted branches are cheap, but do not come free when your CPU is bottlenecked by instruction fetching which often happens in this codec (ZSTD if anyone is interested).
</pre>
<pre class="moz-signature" cols="72">--
Maciej Adamczyk</pre>
</body>
</html>