<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>
<blockquote type="cite"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Code
size data. I care it because code size is critical for
firmware. If possible, please compare them with and without
normal LZMA compression.</span></blockquote>
</p>
Yes, we could measure it.<br>
<br>
<blockquote type="cite"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span
style="mso-list:Ignore">2.<span style="font:7.0pt "Times
New Roman"">
</span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Benchmark
build flag, especially for the optimization level. And what
optimization level do these technologies support? E.g. O1, O3,
Oz, Os, LTO, etc.
</span></blockquote>
It's described on the "Methodology" page:
<a class="moz-txt-link-freetext" href="https://intel-mpx.github.io/methodology/">https://intel-mpx.github.io/methodology/</a><br>
<br>
Best,<br>
Oleksii<br>
<br>
<div class="moz-cite-prefix">On 02/17/2017 04:12 PM, Shi, Steven
wrote:<br>
</div>
<blockquote
cite="mid:06C8AB66E78EE34A949939824ABE2B313B493A3C@shsmsx102.ccr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:522283453;
mso-list-type:hybrid;
mso-list-template-ids:927629632 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi
Oleksenko,<o:p></o:p></span></a></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks
for the report, I’d like to reading through your report more
details. But I hope to know below info as well:<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Code
size data. I care it because code size is critical for
firmware. If possible, please compare them with and without
normal LZMA compression.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span
style="mso-list:Ignore">2.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Benchmark
build flag, especially for the optimization level. And what
optimization level do these technologies support? E.g. O1,
O3, Oz, Os, LTO, etc.
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#1F497D">Steven
Shi</span></b><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p></o:p></span></b></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in
0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
llvm-dev [<a class="moz-txt-link-freetext" href="mailto:llvm-dev-bounces@lists.llvm.org">mailto:llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Oleksii Oleksenko via llvm-dev<br>
<b>Sent:</b> Friday, February 17, 2017 6:05 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> [llvm-dev] Intel MPX support
(instrumentation pass similar to gcc's Pointer
Checker)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Hello,<br>
<br>
even though the study of Intel MPX took much longer than
expected, we have finally finished it. Currently, it is
published in two formats:<br>
<br>
* as a technical report: <a moz-do-not-send="true"
href="https://arxiv.org/abs/1702.00719">https://arxiv.org/abs/1702.00719</a><br>
* and as a webpage: <a moz-do-not-send="true"
href="https://intel-mpx.github.io/">https://intel-mpx.github.io/</a><br>
<br>
This work contains evaluation of MPX from perspectives of
performance (Phoenix, PARSEC, and SPEC benchmark suites),
security (RIPE and found bugs in benchmarks), and usability
(false positives and required changes in applications).
Additionally, we've analyzed various implementation aspects
of Intel MPX and tested it on real-world applications.
<br>
<br>
We would appreciate your feedback.<o:p></o:p></p>
<p><o:p> </o:p></p>
<p class="MsoNormal">Regards,<br>
Oleksii Oleksenko<br>
<br>
<br>
<o:p></o:p></p>
<pre>On 02/09/2016 10:27 PM, Kostya Serebryany via llvm-dev wrote:<o:p></o:p></pre>
<pre>><i> On Tue, Feb 9, 2016 at 7:22 AM, Dmitrii Kuvaiskii <<o:p></o:p></i></pre>
<pre>><i> <a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">Dmitrii.Kuvaiskii at tu-dresden.de</a>> wrote:<o:p></o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>>><i> Thank you Sergey and Konstantin for useful suggestions. We are<o:p></o:p></i></pre>
<pre>>><i> currently bootstrapping the infrastructure for our experiments. We<o:p></o:p></i></pre>
<pre>>><i> would like to make a sufficiently comprehensive report, with not only<o:p></o:p></i></pre>
<pre>>><i> the performance/memory overhead numbers, but also discussing and<o:p></o:p></i></pre>
<pre>>><i> evaluating security guarantees. I will also examine the available<o:p></o:p></i></pre>
<pre>>><i> source codes (ASan, gcc-mpx, SoftBound) and will spend some pages on a<o:p></o:p></i></pre>
<pre>>><i> discussion of the different approaches (trying to do science, you see<o:p></o:p></i></pre>
<pre>>><i> :)).<o:p></o:p></i></pre>
<pre>>><i><o:p> </o:p></i></pre>
<pre>>><i> Btw, I will target only deterministic memory-safety no-code-changes<o:p></o:p></i></pre>
<pre>>><i> approaches that protect against spatial errors (I will probably<o:p></o:p></i></pre>
<pre>>><i> include also ASan and SoftBoundCETS with temporal errors' protection<o:p></o:p></i></pre>
<pre>>><i> in the results as well). The only technique (except Pointer Checker,<o:p></o:p></i></pre>
<pre>>><i> ASan, and SoftBound) I know of is Baggy Bounds Checking from MSR, but<o:p></o:p></i></pre>
<pre>>><i> it seems to be closed-source and Windows-oriented. If anyone can<o:p></o:p></i></pre>
<pre>>><i> suggest some other technique that could be evaluated here, please<o:p></o:p></i></pre>
<pre>>><i> inform me.<o:p></o:p></i></pre>
<pre>>><i><o:p> </o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i> There is also a family of tools originated from Electric Fence<o:p></o:p></i></pre>
<pre>><i> <<a moz-do-not-send="true" href="http://elinux.org/Electric_Fence">http://elinux.org/Electric_Fence</a>>,<o:p></o:p></i></pre>
<pre>><i> they mostly have historical interest due to huge slowdown/memory<o:p></o:p></i></pre>
<pre>><i> consumption.<o:p></o:p></i></pre>
<pre><o:p> </o:p></pre>
<pre>I can assure you that they are still widely used for QA :)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>><i> Are you looking for bug detection mechanisms, or also for production<o:p></o:p></i></pre>
<pre>><i> hardening techniques?<o:p></o:p></i></pre>
<pre>><i> ASan is a bug detection tool. ASan can<o:p></o:p></i></pre>
<pre>><i> <<a moz-do-not-send="true" href="https://blog.torproject.org/blog/tor-browser-55a4-hardened-released">https://blog.torproject.org/blog/tor-browser-55a4-hardened-released</a>> be<o:p></o:p></i></pre>
<pre>><i> used for hardening, but that's not it's primary purpose.<o:p></o:p></i></pre>
<pre>><i> Same is true (IMHO) about Pointer Checker and SoftBound.<o:p></o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i> Hardening is an entirely different subject, although there is a bit of<o:p></o:p></i></pre>
<pre>><i> intersection,<o:p></o:p></i></pre>
<pre>><i> e.g. I know that parts of UBSan (-fsanitize=signed-integer-overflow) are<o:p></o:p></i></pre>
<pre>><i> used for hardening.<o:p></o:p></i></pre>
<pre>><i> In LLVM, also have a look at clang.llvm.org/docs/ControlFlowIntegrity.html<o:p></o:p></i></pre>
<pre>><i> and<o:p></o:p></i></pre>
<pre>><i> <a moz-do-not-send="true" href="http://clang.llvm.org/docs/SafeStack.html">http://clang.llvm.org/docs/SafeStack.html</a><o:p></o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>>><i><o:p> </o:p></i></pre>
<pre>>><i> Anyway, before putting the techreport online, I will send the draft to<o:p></o:p></i></pre>
<pre>>><i> everyone who took part in this conversation, just to be on the safe<o:p></o:p></i></pre>
<pre>>><i> side and correct any bugs/wrong conclusions.<o:p></o:p></i></pre>
<pre>>><i><o:p> </o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i> I would appreciate this.<o:p></o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i> --kcc<o:p></o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>>><i><o:p> </o:p></i></pre>
<pre>>><i> On Tue, Feb 9, 2016 at 3:24 PM, Sergey Ostanevich <<a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">sergos.gnu at gmail.com</a>><o:p></o:p></i></pre>
<pre>>><i> wrote:<o:p></o:p></i></pre>
<pre>>>><i> Dmitrii, all,<o:p></o:p></i></pre>
<pre>>>><i><o:p> </o:p></i></pre>
<pre>>>><i> Please note, that GCC 5.3 had a significant update to the MPX code<o:p></o:p></i></pre>
<pre>>><i> quality -<o:p></o:p></i></pre>
<pre>>>><i> please, use this version as reference.<o:p></o:p></i></pre>
<pre>>>><i><o:p> </o:p></i></pre>
<pre>>>><i> Regards,<o:p></o:p></i></pre>
<pre>>>><i> Sergos<o:p></o:p></i></pre>
<pre>>>><i><o:p> </o:p></i></pre>
<pre>>>><i> On Tue, Feb 9, 2016 at 12:49 AM, Kostya Serebryany via llvm-dev<o:p></o:p></i></pre>
<pre>>>><i> <<a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">llvm-dev at lists.llvm.org</a>> wrote:<o:p></o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i> On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <<a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">kcc at google.com</a>><o:p></o:p></i></pre>
<pre>>><i> wrote:<o:p></o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i> On Thu, Feb 4, 2016 at 4:59 AM, Dmitrii Kuvaiskii<o:p></o:p></i></pre>
<pre>>>>>><i> <<a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">Dmitrii.Kuvaiskii at tu-dresden.de</a>> wrote:<o:p></o:p></i></pre>
<pre>>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>>>>><i> Recently I played with MPX support on Intel C/C++ Compiler (icc).<o:p></o:p></i></pre>
<pre>>>>>>>>><i> This<o:p></o:p></i></pre>
<pre>>>>>>>>><i> implementation looks *much* better, with the following example<o:p></o:p></i></pre>
<pre>>>>>>>>><i> overheads: 1.2X on "raytrace", 1.25X on "bodytrack", 1.08X on<o:p></o:p></i></pre>
<pre>>>>>>>>><i> "streamcluster". So the common overheads are in the range of<o:p></o:p></i></pre>
<pre>>><i> 15%-25%!<o:p></o:p></i></pre>
<pre>>>>>>>><i> That's interesting.<o:p></o:p></i></pre>
<pre>>>>>>>><i> Are you sure you are instrumenting both reads and writes with icc?<o:p></o:p></i></pre>
<pre>>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>>><i> Yes, here are the exact flags I add to the usual build configuration:<o:p></o:p></i></pre>
<pre>>>>>>><i> -xHOST -check-pointers-mpx:rw<o:p></o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i> Interesting, looking forward to reading your report!<o:p></o:p></i></pre>
<pre>>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>>><i> Note "rw" which stands for protecting read and write accesses. In the<o:p></o:p></i></pre>
<pre>>>>>>><i> future, I will analyze how different flags affect ASan / SoftBoundCETS<o:p></o:p></i></pre>
<pre>>>>>>><i> / gcc-mpx / icc-mpx.<o:p></o:p></i></pre>
<pre>>>>>>><i> I will also use a set of microbenchmarks/benchmarks (e.g., RIPE) to<o:p></o:p></i></pre>
<pre>>>>>>><i> test the protection provided.<o:p></o:p></i></pre>
<pre>>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>>>><i> SPEC2006 is well know so it could be useful. Especially<o:p></o:p></i></pre>
<pre>>><i> 483.xalancbmk<o:p></o:p></i></pre>
<pre>>>>>>>><i> Besides, maybe you could take something that is not strictly a<o:p></o:p></i></pre>
<pre>>>>>>>><i> benchmark.<o:p></o:p></i></pre>
<pre>>>>>>>><i> E.g. take pdfium_test (<a moz-do-not-send="true" href="https://pdfium.googlesource.com/pdfium/">https://pdfium.googlesource.com/pdfium/</a>) and<o:p></o:p></i></pre>
<pre>>>>>>>><i> feed<o:p></o:p></i></pre>
<pre>>>>>>>><i> several large pdf files to it.<o:p></o:p></i></pre>
<pre>>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>>><i> Thanks, I will report the SPEC2006 numbers as well.<o:p></o:p></i></pre>
<pre>>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i> Note that SPEC2006 has several know bugs that trigger under asan.<o:p></o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>><i> <a moz-do-not-send="true" href="https://github.com/google/sanitizers/wiki/AddressSanitizerRunningSpecBenchmarks">https://github.com/google/sanitizers/wiki/AddressSanitizerRunningSpecBenchmarks</a><o:p></o:p></i></pre>
<pre>>>>>><i> has a patch that makes SPEC2006 pass with asan.<o:p></o:p></i></pre>
<pre>>>>>><i> Some of these bugs and maybe others may also trigger with an MPX<o:p></o:p></i></pre>
<pre>>><i> checker.<o:p></o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i> Another note: please also try to document the memory footprint.<o:p></o:p></i></pre>
<pre>>>>><i> One of unfortunate features of MPX is its large metadata storage which<o:p></o:p></i></pre>
<pre>>><i> may<o:p></o:p></i></pre>
<pre>>>>><i> in<o:p></o:p></i></pre>
<pre>>>>><i> theory consume as much as 4x more RAM than the application itself.<o:p></o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i> --kcc<o:p></o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i> --kcc<o:p></o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>>><i> --<o:p></o:p></i></pre>
<pre>>>>>>><i> Yours sincerely,<o:p></o:p></i></pre>
<pre>>>>>>><i> Dmitrii Kuvaiskii<o:p></o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>>><i> _______________________________________________<o:p></o:p></i></pre>
<pre>>>>><i> LLVM Developers mailing list<o:p></o:p></i></pre>
<pre>>>>><i> <a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">llvm-dev at lists.llvm.org</a><o:p></o:p></i></pre>
<pre>>>>><i> <a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></i></pre>
<pre>>>>><i><o:p> </o:p></i></pre>
<pre>>>><i><o:p> </o:p></i></pre>
<pre>>><i><o:p> </o:p></i></pre>
<pre>>><i> --<o:p></o:p></i></pre>
<pre>>><i> Yours sincerely,<o:p></o:p></i></pre>
<pre>>><i> Dmitrii Kuvaiskii<o:p></o:p></i></pre>
<pre>>><i><o:p> </o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i> _______________________________________________<o:p></o:p></i></pre>
<pre>><i> LLVM Developers mailing list<o:p></o:p></i></pre>
<pre>><i> <a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">llvm-dev at lists.llvm.org</a><o:p></o:p></i></pre>
<pre>><i> <a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></i></pre>
<pre>><o:p> </o:p></pre>
<pre>-- <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Best Regards,<o:p></o:p></pre>
<pre>Oleksii Oleksenko<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>TU Dresden<o:p></o:p></pre>
<pre>Faculty of Computer Science<o:p></o:p></pre>
<pre>Chair of Systems Engineering<o:p></o:p></pre>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best Regards,
Oleksii Oleksenko
TU Dresden
Faculty of Computer Science
Chair of Systems Engineering</pre>
</body>
</html>