[llvm-dev] Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)

[Sergey Ostanevich via llvm-dev]

Dmitrii, all,

Please note, that GCC 5.3 had a significant update to the MPX code quality
- please, use this version as reference.

Regards,
Sergos

On Tue, Feb 9, 2016 at 12:49 AM, Kostya Serebryany via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>> On Thu, Feb 4, 2016 at 4:59 AM, Dmitrii Kuvaiskii <
>> Dmitrii.Kuvaiskii at tu-dresden.de> wrote:
>>
>>> >> Recently I played with MPX support on Intel C/C++ Compiler (icc). This
>>> >> implementation looks *much* better, with the following example
>>> >> overheads: 1.2X on "raytrace", 1.25X on "bodytrack", 1.08X on
>>> >> "streamcluster". So the common overheads are in the range of 15%-25%!
>>> > That's interesting.
>>> > Are you sure you are instrumenting both reads and writes with icc?
>>>
>>> Yes, here are the exact flags I add to the usual build configuration:
>>>   -xHOST -check-pointers-mpx:rw
>>>
>>
>> Interesting, looking forward to reading your report!
>>
>>>
>>> Note "rw" which stands for protecting read and write accesses. In the
>>> future, I will analyze how different flags affect ASan / SoftBoundCETS
>>> / gcc-mpx / icc-mpx.
>>> I will also use a set of microbenchmarks/benchmarks (e.g., RIPE) to
>>> test the protection provided.
>>>
>>> > SPEC2006 is well know so it could be useful. Especially 483.xalancbmk
>>> > Besides, maybe you could take something that is not strictly a
>>> benchmark.
>>> > E.g. take pdfium_test (https://pdfium.googlesource.com/pdfium/) and
>>> feed
>>> > several large pdf files to it.
>>>
>>> Thanks, I will report the SPEC2006 numbers as well.
>>>
>>>
>> Note that SPEC2006 has several know bugs that trigger under asan.
>>
>> https://github.com/google/sanitizers/wiki/AddressSanitizerRunningSpecBenchmarks
>> has a patch that makes SPEC2006 pass with asan.
>> Some of these bugs and maybe others may also trigger with an MPX checker.
>>
>
> Another note: please also try to document the memory footprint.
> One of unfortunate features of MPX is its large metadata storage which may
> in
> theory consume as much as 4x more RAM than the application itself.
>
> --kcc
>
>
>>
>> --kcc
>>
>> --
>>> Yours sincerely,
>>> Dmitrii Kuvaiskii
>>>
>>
>>
>
> _______________________________________________
> 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/20160209/a5042519/attachment.html>