<div dir="ltr">I know Hal and Mehdi are already aware, but for the wider audience and back reference, we recently had some discussions about the broken state of fast-math in:<br><a href="https://reviews.llvm.org/D24816" target="_blank">https://reviews.llvm.org/D2481<wbr>6</a> (<span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">[Target] move reciprocal estimate settings from TargetOptions to TargetLowering)</span><div><a href="https://reviews.llvm.org/D24815" target="_blank">https://reviews.llvm.org/D2481<wbr>5</a> (<span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">[clang] make reciprocal estimate codegen a function attribute)<br><br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">Starting by fixing the IR flags is likely the best first step because if we fix the backend first, we may expose more bugs-on-top-of-bugs as described here:<br><a href="https://llvm.org/bugs/show_bug.cgi?id=27372#c5" target="_blank">https://llvm.org/bugs/show_bug<wbr>.cgi?id=27372#c5</a><br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header"><br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">But we may need a bigger change than just removing the umbrella effect of 'fast':<br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">When I started looking at how we could move the reciprocal-estimate setting (this is different than 'arcp') to instructions, I noted that the existing FMF uses Value's SubclassOptionalData. <br><br>I'm guessing this is for maximum performance, </span><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header"><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">but SubclassOptionalData is exactly 7 bits, and we've already burned 5 of them. </span>So if we need more refinement than 'fast' / 'aggr' to express what's possible via the front-end flags, we either need to expand SubclassOptionalData, add a custom field for FMF, or move FMF to metadata or attributes. I'm assuming the first 2 options are much larger undertakings than the third.<br><br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">For reciprocal-estimates, using the existing FMF/SubclassOptionalData isn't a viable solution because there's no way to express all of the front-end info (number of refinement steps, etc) in 2 bits. So what about metadata? We already have an instruction-level metadata type called "MD_fpmath". AFAICT, it's currently only used to indicate a reduced accuracy operation for AMDGPU. So I was hoping to just add an option to that metadata type for reciprocal-estimates.<br><br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">I realize that metadata is optional (ie, it can be dropped without affecting correctness). I think that's fine for reciprocal-estimates, but I'm not sure. Are -ffast-math and friends optional optimization flags? Or do we consider those non-optional modes of execution? If they are not optional, then should we have instruction-level attributes for FMF? This possibility came up when we enabled FMF on calls ( <a href="https://reviews.llvm.org/D14707" target="_blank">https://reviews.llvm.org/<wbr>D14707</a> ).<br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header"><br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">Apologies for raising too many issues at once, but consider that another potential subclass of relaxed-FP-math was recently discussed here:<br><a href="https://reviews.llvm.org/D26602">https://reviews.llvm.org/D26602</a><br><br></span></div><div><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493gmail-phui-header-header">Is a "distributive" transform different than an "associative" transform?<br><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 16, 2016 at 12:59 AM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><br><hr id="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202zwchr"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:helvetica,arial,sans-serif;font-size:12pt"><b>From: </b>"Mehdi Amini via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>To: </b>"Warren Ristow" <<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a>><br><b>Cc: </b><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><b>Sent: </b>Tuesday, November 15, 2016 11:10:48 PM<br><b>Subject: </b>Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags<div><div class="gmail-m_-817267587472893295gmail-m_-602149580839763493h5"><br><br>
Hi,<div><br><div><blockquote><div>On Nov 15, 2016, at 5:15 PM, Ristow, Warren via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202Apple-interchange-newline"><div><div class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202WordSection1" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">Hi all,</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">This is about<span class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202Apple-converted-space"> </span><a href="https://reviews.llvm.org/D26708" style="color:rgb(149,79,114);text-decoration:underline" target="_blank">https://reviews.llvm.org<wbr>/D26708</a></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">Currently when the command-line switch '-ffast-math' is specified, the</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">IR-level fast-math-flag 'fast' gets attached to appropriate FP math</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">instructions.  That flag acts as an "umbrella" to implicitly turn on all the</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">other fast-math-flags ('nnan', 'ninf', 'nsz' and 'arcp'):</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""><a href="http://llvm.org/docs/LangRef.html#fast-math-flags" style="color:rgb(149,79,114);text-decoration:underline" target="_blank">http://llvm.org/docs/LangRef.h<wbr>tml#fast-math-flags</a></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">This approach has the shortcoming that when there is a desire to disable one</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">of these fast-math-flags, if the 'fast' flag remains, it implicitly</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">re-enables the one being disabled.  For example, compiling this test-case:</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    extern void use(float x, float y);</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    void test(float a, float b, float c) {</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">      float q1 = a / c;</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">      float q2 = b / c;</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">      use(q1, q2);</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    }</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">at '-O2 -ffast-math' does a reciprocal-transformation, so only one division</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">is done (as desired with fast-math).  Compiling it with:</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">  -O2 -ffast-math -fno-reciprocal-math</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">should disable the reciprocal transformations (the flag 'arcp'), but leave</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">all the other fast-math transformations enabled.  The current implementation</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">doesn't do that, since the 'fast' IR-level flag still gets set.</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">Motivation of this discussion:<span class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202Apple-converted-space"> </span><a href="https://llvm.org/bugs/show_bug.cgi?id=27372#c2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank">https://llvm.org/b<wbr>ugs/show_bug.cgi?id=27372#c2</a></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">As an aside, when '-ffast-math' is specified on the command-line, the</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">following six switches are all passed to cc1:</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    -menable-no-infs</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    -menable-no-nans</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    -fno-signed-zeros</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    -freciprocal-math</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    -fno-trapping-math</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">    -ffp-contract=fast</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">and '-ffast-math' itself is also passed cc1 (the act of passing '-ffast-math'</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">to cc1 results in the macro '__FAST_MATH__' being defined).  When (for</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">example) '-fno-reciprocal-math' is passed in addition to '-ffast-math', then</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">'-freciprocal-math' is no longer passed to cc1 (and the other five listed</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">above still are passed, along with '-ffast-math' still being passed).  It</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">seems like the intention was that these individual switches were to enable</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">the individual floating-point transformations (and so the lack of any of</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">those switches would suppress the relevant transformations), but the</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">'-ffast-math' "umbrella" is over-riding the attempted suppression.</span></div></div></div></blockquote><div><br></div><div>Sure, this looks like a bug, disable an individual fast-math flag on the command line should be possible and override a prior -ffast-math (usually the last one on the command line “wins”/override).</div><div><br></div><div>The Cfe-dev mailing list would be more appropriate to discuss the behavior of clang command line flags though.</div><div><br></div><br><blockquote><div><div class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202WordSection1" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">The change proposed at<span class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202Apple-converted-space"> </span><a href="https://reviews.llvm.org/D26708" style="color:rgb(149,79,114);text-decoration:underline" target="_blank">https://reviews.llvm.org/D2<wbr>6708</a><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202Apple-converted-space"> </span>deals with this issue</span></div></div></div></blockquote><div><br></div><div>This patch seems to modify on LLVM, it does not deal at all with the issue you describe above. </div><div>I don’t see why the issue with the clang command line flags need to be dealt with at the LLVM level.</div><div><br></div><br><blockquote><div><div class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202WordSection1" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">just for the reciprocal-transformation case, but it changes the semantics of</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">the 'fast' IR-level flag so that it no longer implies all the others. </span></div></div></div></blockquote><div><br></div><div>The starting point for any change is: <a href="http://llvm.org/docs/LangRef.html#fast-math-flags" target="_blank">http://llvm.org/docs/LangRef.h<wbr>tml#fast-math-flags</a></div><div>You would need to write a new definition for what “fast” would mean.</div><div><br></div><div id="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202DWT3626">However I don’t need anything need to be changed here to address the use-case you want to fix.</div></div></div></div></div></blockquote>I suspect that we want to start by getting rid of 'fast' on the IR level and replacing it with individual flags for the various optimization classes - Do we have only allowing reassociation and libm optimizations? Then we can readjust the Clang flags in a straightforward way.<br><br> -Hal<br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:helvetica,arial,sans-serif;font-size:12pt"><span><div><div><div></div><div><br></div><div><br></div><blockquote><div><div class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202WordSection1" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> With</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">that proposed approach, rather than an "umbrella" flag such as 'fast' being</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">checked in the back-end (along with an individual flag like 'arcp'), just</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">checking the individual flag ('arcp') would be done. </span></div></div></div></blockquote><div><br></div><div>There is already no need to check the “fast” *and* arcp flag, if a transformation is about reciprocal, then you only need to check arcp (fast implies arcp, checking for fast would be redundant).</div><div><br></div><div>Be careful also that the fast-math flags are mainly an IR level definition, the backend only inherited these per instruction flag very recently. It has been entirely converted to use these, and it still uses a global flag in some places.</div><div>The line you’re touching in your patch for instance is about this legacy:</div><div><br></div><div>  if (!UnsafeMath && !Flags->hasAllowReciprocal())</div><div><br></div><div>The first flag is the global “fast-math” mode on the backend, which is not as fine grain as the per-instruction model.</div><div>The second flag is the “per instruction” flag, which is the model we aim at.</div><div><br></div><div>We should get rid of the “global” UnsafeMath in the backend, but that does not require any change to the IR or the individual fast-math flags.</div><div><br></div><div><br></div><blockquote><div><div class="gmail-m_-817267587472893295gmail-m_-602149580839763493m_5945689990331756202WordSection1" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> Any fast-math-related</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">transformation that doesn't have an individual flag (e.g., re-association</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">currently doesn't), should eventually have an individual flag defined for</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">it, and then that individual flag should be checked.</span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new""> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-family:"courier new"">What do people think?</span></div></div></div></blockquote><div><br></div></div><div>I think these are valuable problems to solve, but you should tackle them piece by piece: </div><div><br></div><div>1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix.</div><div>2) the backend is still using the global UnsafeFPMath and it should be killed.</div><div><br></div><div>Hope this makes sense.</div><div><br></div><div>— </div><div>Mehdi</div><div><br></div></div><br></span>______________________________<wbr>_________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493HOEnZb"><font color="#888888"><br></font></span></blockquote><span class="gmail-m_-817267587472893295gmail-m_-602149580839763493HOEnZb"><font color="#888888"><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></font></span></div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>