<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
+1 to this. Having it structured this way would make things much
easier if we someday decided to promote these intrinsics to
instructions or merge them (via non-optional modifiers like
"volatile") with the existing floating point instructions. <br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 02/05/2016 06:03 PM, Chandler
Carruth via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KiMRTfCW91pJvrkUTbGYQNRzg_e2_30KLUt6+POngh3jw@mail.gmail.com"
type="cite">
<div dir="ltr">Agreed.</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Feb 5, 2016 at 5:54 PM Pete Cooper via
llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">FWIW, +1
from me.<br>
<br>
Just one request on the implementation though. However we
model these intrinsics and their properties (metadata,
constants, etc), can we please abstract away those details the
same way we have MemCpyInst which just wraps an IntrinsicInst?<br>
<br>
I think this would be very beneficial if we ever need to add
more state, or change something about the underlying
implementation, and not have to search all the code for ‘bool
traps =
cast<ConstantInt>(I->getOperand(1))->getZextValue()’
or whatever it happens to be.<br>
<br>
Pete<br>
> On Feb 5, 2016, at 4:36 PM, Stephen Canon via llvm-dev
<<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
><br>
> Seems like everyone’s on board, but I want to mention
that I also think this is very much the right approach. In
particular, it allows us to support both existing CPU designs
with dynamic rounding modes as well as GPU designs and
soft-float libraries with statically specified rounding.<br>
><br>
> Support for “I want the flags, but I really don’t care
about when they happen specifically” is somewhat interesting;
I assume this would take the form of “returning” the flag
state and OR-ing it into an integer that represents the
cumulative flags (much like common cpu hardware does, but this
would also let us support soft-float implementations). This
wouldn’t impose ordering restrictions, but would prevent
speculation.<br>
><br>
> – Steve<br>
><br>
>> On Feb 5, 2016, at 4:25 PM, Hal Finkel via llvm-dev
<<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
>><br>
>> ----- Original Message -----<br>
>>> From: "Chandler Carruth" <<a
moz-do-not-send="true" href="mailto:chandlerc@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a></a>><br>
>>> To: "Hal Finkel" <<a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>,
"Chandler Carruth" <<a moz-do-not-send="true"
href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>><br>
>>> Cc: "llvm-dev" <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>>> Sent: Friday, February 5, 2016 4:36:54 PM<br>
>>> Subject: Re: [llvm-dev] [RFC] FP Environment and
Rounding mode handling in LLVM<br>
>>><br>
>>> On Fri, Feb 5, 2016 at 2:10 PM Hal Finkel via
llvm-dev <<br>
>>> <a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
> wrote:<br>
>>><br>
>>><br>
>>> Hi Chandler,<br>
>>><br>
>>> This scheme has significant advantages over what
was being pursued,<br>
>>> but one question (or two)...<br>
>>><br>
>>> Under the proposed system, how would you
represent the necessary<br>
>>> dependency edges between the fp intrinsics and
function calls? How<br>
>>> is the state 'returned' to the caller? [I was
thinking that our new<br>
>>> operand bundles could help for the inputs, but
the outputs? Plus<br>
>>> what about the live-in state?]<br>
>>><br>
>>> This is important because any external subroutine
call could<br>
>>> (potentially) change the rounding mode or any
other part of the<br>
>>> floating-point environment.<br>
>>><br>
>>><br>
>>><br>
>>> So, one thing that was missing in my original
email and that talking<br>
>>> with Steve Canon offline clarified was that we
need a way to<br>
>>> directly query the current modes for systems
where those can be set<br>
>>> externally.<br>
>>><br>
>>><br>
>>> My suggestion was to have an intrinsic that
"loads" this state. This<br>
>>> could then be used to load whatever the current
state is, and pass<br>
>>> that to the floating point intrinsics proposed in
order to pick up<br>
>>> whatever the "current" state happens to be on
systems where this is<br>
>>> truly a background stateful thing, while still
allowing us to model<br>
>>> operation-specific state for other systems.
Naturally, there should<br>
>>> be a complimenting "store" of the state as well.<br>
>>><br>
>>><br>
>>> Then, for code which really needs this degree of
faithful FP<br>
>>> environment handling, you would expect the
#pragma to be present<br>
>>> enabling that mode. While that pragma is in
place, all floating<br>
>>> point operations would be lowered using these
intrinsics, and<br>
>>> external function calls could be guarded by
storing and reloading<br>
>>> this state at the IR level. This would make the
IR substantially<br>
>>> more verbose when the pragma is enabled, but that
seems like an<br>
>>> acceptable tradeoff given that we expect this
code to be rare (see<br>
>>> my preconditions section). And naturally, on any
system that<br>
>>> actually manages FP environment in a state
"register" or whatever,<br>
>>> we'd want to do some work to try to optimize away
state changes.<br>
>>> Much like we have attributes that can be inferred
about access to<br>
>>> memory, we could infer attributes on functions
about whether they<br>
>>> change the FP environment state, and if not,
propagate across the<br>
>>> function call boundaries.<br>
>>><br>
>>><br>
>>> But even though this would be some amount of work
to optimize, the<br>
>>> nice thing (IMO) is that it would be localized.
We would have<br>
>>> specific code that dealt with optimizing the FP
environment<br>
>>> concerns, while the rest of LLVM could remain
oblivious and rely on<br>
>>> simple common constructs to provide
conservatively correct behavior.<br>
>>><br>
>>> What do you think?<br>
>><br>
>> SGTM.<br>
>><br>
>> -Hal<br>
>><br>
>>> -Chandler<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Thanks again,<br>
>>> Hal<br>
>>><br>
>>> ----- Original Message -----<br>
>>>> From: "Chandler Carruth" < <a
moz-do-not-send="true" href="mailto:chandlerc@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a></a> ><br>
>>>> To: "Mehdi Amini" < <a
moz-do-not-send="true" href="mailto:mehdi.amini@apple.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a></a> >, "llvm-dev"
<<br>
>>>> <a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
><br>
>>>> Cc: "Steve (Numerics) Canon" < <a
moz-do-not-send="true" href="mailto:scanon@apple.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:scanon@apple.com">scanon@apple.com</a></a> >, "Sergey<br>
>>>> Dmitrouk" < <a moz-do-not-send="true"
href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>
>, "David Majnemer"<br>
>>>> < <a moz-do-not-send="true"
href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>
>, "Hal Finkel" < <a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>
><br>
>>>> Sent: Thursday, February 4, 2016 8:05:38 PM<br>
>>>> Subject: Re: [RFC] FP Environment and
Rounding mode handling in<br>
>>>> LLVM<br>
>>>><br>
>>>><br>
>>>> First, thanks Mehdi for putting something on
llvm-dev and getting<br>
>>>> wider awareness of this.<br>
>>>><br>
>>>><br>
>>>> I am actually really interested in finding a
way for LLVM to<br>
>>>> support<br>
>>>> the interesting functionality we are missing
from fenv-like<br>
>>>> interfaces. Things like rounding modes,
exceptions, etc. However, I<br>
>>>> think the current design is going to be a
really high burden for<br>
>>>> the<br>
>>>> entire optimizer and I think there is a
simpler model that we might<br>
>>>> pursue instead.<br>
>>>><br>
>>>><br>
>>>> I'll start off with some underlying
principles that I'm operating<br>
>>>> from:<br>
>>>> a) Most code in the world will be very happy
with the default<br>
>>>> floating point environment, doesn't need to
carefully model<br>
>>>> floating<br>
>>>> point exceptions, etc. Essentially, I think
that LLVM's behavior<br>
>>>> today is probably right for most code. Now,
the code which needs<br>
>>>> support for the other features of floating
point isn't bad or<br>
>>>> unimportant! But it is relatively speaking
rare, and so I think it<br>
>>>> is reasonable to optimize the
*representation* model for the common<br>
>>>> case provided we don't lose support for
functionality.<br>
>>>><br>
>>>><br>
>>>> a) When outside the default floating point
environment's rules,<br>
>>>> there<br>
>>>> are few if any optimizations that we
realistically expect from<br>
>>>> LLVM.<br>
>>>> Certainly, any changes to the LLVM optimizer
which impact code<br>
>>>> outside the default needs to be done *much*
more carefully to avoid<br>
>>>> introducing subtle bugs.<br>
>>>><br>
>>>><br>
>>>> OK, based on that, consider the following
model:<br>
>>>> We provide intrinsics that mirror the
instructions 'fadd', 'fsub',<br>
>>>> 'fmul', 'fdiv', and 'frem' (so 5 total). From
here on out, I'll<br>
>>>> exclusively use 'fadd' as my examples. The
intrinsics would look<br>
>>>> like:<br>
>>>><br>
>>>> declare {f32, i1}
@llvm.fadd.with.environment.f32(f32 %lhs, f32<br>
>>>> %rhs,<br>
>>>> i8 %rounding_mode, i8 %exception_behavior)<br>
>>>><br>
>>>><br>
>>>> Then we define specific values to be used for
the IEEE rounding<br>
>>>> modes. And we define values to control
exception behavior. I'm not<br>
>>>> an expert on floating point exceptions in
particular (my platforms<br>
>>>> don't use them) but I'm imagining three
states "ignore", "return",<br>
>>>> and "trap". I've used a single 'i1', but I'm
assuming it would need<br>
>>>> to be several i1s or an iN in order to model
the set of FP<br>
>>>> exceptions. I'm using i1 here just to
simplify the explanation, I<br>
>>>> think it generalizes and I'll let the experts
suggest the exact<br>
>>>> formulation.<br>
>>>><br>
>>>><br>
>>>> If the default rounding mode is provided to
these intrinsics and<br>
>>>> the<br>
>>>> "ignore" exception behavior is provided, they
behave exactly as the<br>
>>>> existing instructions do, and instcombine
should canonicalize to<br>
>>>> the<br>
>>>> existing instructions.<br>
>>>><br>
>>>><br>
>>>> The semantics of non-default rounding modes
are to perform the<br>
>>>> operation with that rounding mode.<br>
>>>><br>
>>>><br>
>>>> If "return" is provided for the exception
behavior, then the i1<br>
>>>> component of the result is true if an FP
exception occured and<br>
>>>> false<br>
>>>> otherwise. If "ignore" is provided then any
FP exceptions are<br>
>>>> ignored and the i1 is always false. If "trap"
is provided then the<br>
>>>> i1 is always false, but the call to the
intrinsic might trap. We<br>
>>>> could either define a trap as precisely the
same as a call to<br>
>>>> @llvm.trap(), or we could introduce an
@llvm.fp.trap() and define<br>
>>>> it<br>
>>>> as a call to that.<br>
>>>><br>
>>>><br>
>>>> The frontend would then be responsible for
lowering floating point<br>
>>>> arithmetic using these intrinsics. This may
be somewhat challenging<br>
>>>> because in the frontend behavior is
controlled dynamically in some<br>
>>>> languages. In those situations, we can either
allow these<br>
>>>> intrinsics<br>
>>>> to accept non-constant arguments for
%rounding_mode and<br>
>>>> %exception_behavior so that frontends can
emit code that just<br>
>>>> dynamically computes them, or we could follow
the same model that<br>
>>>> atomics use, and if the frontend cannot
trivially compute a<br>
>>>> constant, it can emit a switch over the
possible states with a<br>
>>>> specific intrinsic call in each case. I don't
have strong opinions<br>
>>>> about which would be best, I think either
could be made to work.<br>
>>>><br>
>>>><br>
>>>> If we go with constant arguments being
required, we could use<br>
>>>> "metadata arguments" which aren't actually
metadata but just<br>
>>>> encoded<br>
>>>> arguments for intrinsics.<br>
>>>><br>
>>>><br>
>>>> When emitting constants and trying to respect
floating point<br>
>>>> environment settings, frontends will have to
emit runtime calls<br>
>>>> instead of actual constants. But this seems
actually good because<br>
>>>> that is what we'll need anyways -- we aren't
able to with full<br>
>>>> generality emulate all the environment
options if I understand<br>
>>>> things correctly (and let me know if I've
misunderstood).<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> The two really big reasons why I like this
model much more than<br>
>>>> extending flags are:<br>
>>>><br>
>>>><br>
>>>> 1) This avoids implicit state. The implicit
state of the floating<br>
>>>> point environment makes things like code
motion extremely hard to<br>
>>>> reason about. I think we will just get it
wrong too often to make<br>
>>>> this a good approach. By modeling all of this
as actual SSA values<br>
>>>> I<br>
>>>> think there is a much better chance we'll get
this stuff right. For<br>
>>>> example by or-ing all the i1s for floating
point exceptions and<br>
>>>> testing the result to implement fetestexcept.
Then the backend can<br>
>>>> spill the state when necessary and reload it
when needed even if<br>
>>>> other floating point math is introduced. I
admit that first class<br>
>>>> aggregate returns aren't a beautiful way to
encapsulate this, but<br>
>>>> they are an *effective* way that we know how
to work with in the<br>
>>>> LLVM IR. If we ever come up with a better
multi-def model, we can<br>
>>>> always switch these and all the other
intrinsics which need this to<br>
>>>> that model.<br>
>>>><br>
>>>><br>
>>>> 2) Every pass will conservatively correctly
model the operations.<br>
>>>> This is most significant when modeling
trapping on exceptions. We<br>
>>>> need every pass to realize that control flow
might not proceed past<br>
>>>> such operations. We already have this logic
for calls, and it seems<br>
>>>> a really nice fit for allowing most of the
optimizer to be unaware<br>
>>>> of these constructs while respecting them and
preserving behavior<br>
>>>> in<br>
>>>> the face of them.<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> I suspect that there are things this model
doesn't handle that I've<br>
>>>> not thought of (as this is outside the are of
FP that I'm deeply<br>
>>>> familiar with), but I really think this model
would be easier to<br>
>>>> reason about and would be much less invasive
within the IR and<br>
>>>> optimizer. I wonder if folks think this could
work and would be up<br>
>>>> for moving their efforts in this direction?<br>
>>>><br>
>>>><br>
>>>> -Chandler<br>
>>>><br>
>>>><br>
>>>> On Wed, Feb 3, 2016 at 3:04 PM Mehdi Amini
< <a moz-do-not-send="true"
href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a><br>
>>>>><br>
>>>> wrote:<br>
>>>><br>
>>>><br>
>>>> Hi everyone,<br>
>>>><br>
>>>> Sergey (CC’ed) worked on a series of patches
to add support for<br>
>>>> floating-point environment and floating-point
rounding modes in<br>
>>>> LLVM.<br>
>>>> This started *in 2014* and the patches after
multiple rounds of<br>
>>>> review in the last months (involving amongst
other Steve Canon, Hal<br>
>>>> Finkel, David Majnemer, and myself) are
getting very close (IMO) to<br>
>>>> be in a state where we can land them.<br>
>>>><br>
>>>> This is the thread that started this
development: “ [LLVMdev] More<br>
>>>> careful treatment of floating point
exceptions"<br>
>>>> <a moz-do-not-send="true"
href="http://marc.info/?l=llvm-dev&m=141113983302113&w=2"
rel="noreferrer" target="_blank">http://marc.info/?l=llvm-dev&m=141113983302113&w=2</a><br>
>>>> And this is the thread where most of the
discussion on the design<br>
>>>> occurred: "[PATCH] Flag to enable IEEE-754
friendly FP<br>
>>>> optimizations”<br>
>>>> <a moz-do-not-send="true"
href="http://marc.info/?l=llvm-commits&m=141235814915999&w=2"
rel="noreferrer" target="_blank">http://marc.info/?l=llvm-commits&m=141235814915999&w=2</a><br>
>>>><br>
>>>> Since Chandler raised some concerns on IRC
today, so I figured I<br>
>>>> should send a heads-up on this topic to allow
any one to comment on<br>
>>>> the current plan.<br>
>>>><br>
>>>> We plan on adding two new FP env flags to the
existing FMF<br>
>>>> (fast-math<br>
>>>> flags). Without these flags set, the
optimizer has to assume that<br>
>>>> the FP env can be observed, or the rounding
mode can be changed.<br>
>>>> For<br>
>>>> clang, these flags would be set unless a
command line option would<br>
>>>> require to preserve the FP env.<br>
>>>><br>
>>>> Here is the list of patches:<br>
>>>><br>
>>>> [FPEnv Core 01/14] Add flags and command-line
switches for FPEnv:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14066" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14066</a><br>
>>>> [FPEnv Core 02/14] Add FPEnv access flags to
fast-math flags:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14067" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14067</a><br>
>>>> [FPEnv Core 03/14] Make SelectionDAG aware of
FPEnv flags:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14068" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14068</a><br>
>>>> [FPEnv Core 04/14] Skip constant folding to
preserve FPEnv:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14069" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14069</a><br>
>>>> [FPEnv Core 05/14] Teach IR builder and
folders about new flags:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14070" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14070</a><br>
>>>> [FPEnv Core 06/14] Do not fold constants on
reading in IR<br>
>>>> asm/bitcode: <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14071" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14071</a><br>
>>>> [FPEnv Core 07/14] Prevent undesired folding
by InstSimplify:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14072" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14072</a><br>
>>>> [FPEnv Core 08/14] Do not simplify
expressions with FPEnv access:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14073" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14073</a><br>
>>>> [FPEnv Core 09/14] Make Strict flag available
for more clients:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14074" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14074</a><br>
>>>> [FPEnv Core 10/14] Use Strict in IRBuilder:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14075" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14075</a><br>
>>>> [FPEnv Core 11/14] Don't convert fpops to
constexprs in SCCP:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14076" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14076</a><br>
>>>> [FPEnv Core 13/14] Don't hoist FP-ops with
side-effects in LICM:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14078" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14078</a><br>
>>>> [FPEnv Core 14/14] Introduce F*_W_CHAIN
instrs to prevent<br>
>>>> reordering:<br>
>>>> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D14079" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D14079</a><br>
>>>><br>
>>>><br>
>>>> —<br>
>>>> Mehdi<br>
>>>><br>
>>>><br>
>>><br>
>>> --<br>
>>> Hal Finkel<br>
>>> Assistant Computational Scientist<br>
>>> Leadership Computing Facility<br>
>>> Argonne National Laboratory<br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>> <a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>>><br>
>><br>
>> --<br>
>> Hal Finkel<br>
>> Assistant Computational Scientist<br>
>> Leadership Computing Facility<br>
>> Argonne National Laboratory<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>