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

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.

--kcc

--
> Yours sincerely,
> Dmitrii Kuvaiskii
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160204/f8ce156c/attachment.html>

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160208/844ce849/attachment.html>

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>