Mehdi Amini via llvm-dev
2016-Mar-25 22:43 UTC
[llvm-dev] RFC: New aggressive dead code elimination pass
> On Mar 25, 2016, at 3:30 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Make most things update post-dominance info and preserve it. > > Our other alternative to not take up too much time seems to be invasive surgery on how BB successors/predecessors work so they are a constant time array. I say this because GCC recomputes post-dominators roughly 15-19 times per compilation, and can do it about 3-5x faster than we can. All profiling i've done basically says all our time is spent trying to get at successors and predecessors in dominance/post-dominance respectively, which takes basically no time in gcc, because the edge lists are an array. > > (Note that if you look at generic dominance code, like http://www.cs.princeton.edu/~rwerneck/dominators/ <http://www.cs.princeton.edu/~rwerneck/dominators/>, it's much faster than what we do on the same graphs. This is true even though we use the same algorithms .....) > > Given it seems unlikely we are going to change the internal representation anytime soon (or at least i've not seen a proposal), updating post-dom seems the easier answer.Are we talking about the basic-blocks edges only? I'm not sure changing the IR for the BBs would be a lot more work than preserving dominance analysis everywhere, or I am totally underestimating one / overestimating the other? -- Mehdi> > > On Thu, Mar 24, 2016 at 11:56 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: > What do you have in mind here? > > > On Thu, Mar 24, 2016, 7:28 PM Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Yeah, that was gonna be my question. > If so, my view is we should just bite the bullet and start threading post dominance through the compiler. > (assuming anyone wants to help. I'm tackling the memoryssa updating stuff with george ATM). > > > > On Thu, Mar 24, 2016 at 7:04 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: > [+Danny] > > ----- Original Message ----- > > From: "Justin Bogner via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > > To: "David Callahan via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > > Sent: Wednesday, March 23, 2016 12:36:50 PM > > Subject: Re: [llvm-dev] RFC: New aggressive dead code elimination pass > > > > David Callahan via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> writes: > > > Hi, > > > > > > I have a new variant of Aggressive Dead Code Elimination that also > > > removes dead branching. It is designed to minimize the cost of > > > control-dependence analysis in the common case where almost the > > > entire > > > program is live. It also can optionally remove dead but > > > may-be-infinite loops. > > > > > > When enabled for –O3 (replacing current ADCE pass) and removing > > > loops, > > > impact on SPEC2006 is in the noise but it impacts internal > > > benchmarks > > > suites 1-2% with a comparable increase in compile time. My > > > expectation would be to enable –O3 only until we have some > > > experience > > > with cost but I suspect it should be fine –O2. > > > > Just to clarify, you're saying that both runtime and compile time > > impact > > were in the noise on SPEC, right? > > > > > What information would the community like to see about such a > > > change > > > before I put up a diff and (including tweaks to unit tests). > > > > I'm not sure that there's much to discuss in the abstract - it's much > > easier to evaluate this kind of thing when there's a patch to refer > > to. > > Presumably people will want to try the patch out on their own > > internal > > benchmarks as well. > > +1 > > Does it use post-dominance information? > > -Hal > > > > > > Thanks > > > david > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > _______________________________________________ > 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/20160325/b346b40d/attachment.html>
Hal Finkel via llvm-dev
2016-Mar-25 22:52 UTC
[llvm-dev] RFC: New aggressive dead code elimination pass
----- Original Message -----> From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "David Callahan via llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, March 25, 2016 5:43:12 PM > Subject: Re: [llvm-dev] RFC: New aggressive dead code elimination > pass> > On Mar 25, 2016, at 3:30 PM, Daniel Berlin via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: >> > Make most things update post-dominance info and preserve it. >> > Our other alternative to not take up too much time seems to be > > invasive surgery on how BB successors/predecessors work so they are > > a constant time array. I say this because GCC recomputes > > post-dominators roughly 15-19 times per compilation, and can do it > > about 3-5x faster than we can. All profiling i've done basically > > says all our time is spent trying to get at successors and > > predecessors in dominance/post-dominance respectively, which takes > > basically no time in gcc, because the edge lists are an array. >> > (Note that if you look at generic dominance code, like > > http://www.cs.princeton.edu/~rwerneck/dominators/ , it's much > > faster > > than what we do on the same graphs. This is true even though we use > > the same algorithms .....) >> > Given it seems unlikely we are going to change the internal > > representation anytime soon (or at least i've not seen a proposal), > > updating post-dom seems the easier answer. > > Are we talking about the basic-blocks edges only? I'm not sure > changing the IR for the BBs would be a lot more work than preserving > dominance analysis everywhere, or I am totally underestimating one / > overestimating the other?I'm also curious about this, especially because I'd naively think that: representation change == a little thinking and (potentially) a lot of typing preserving post dom == a lot of thinking and a little typing and, thus, while updating the analysis might be the *right* thing to do, it is probably not easier (especially once you factor in the time taken to fix bugs where we subtly get it wrong). Maybe in the long run, we should do both? -Hal> -- > Mehdi> > On Thu, Mar 24, 2016 at 11:56 PM, Eric Christopher < > > echristo at gmail.com > wrote: >> > > What do you have in mind here? > > >> > > On Thu, Mar 24, 2016, 7:28 PM Daniel Berlin via llvm-dev < > > > llvm-dev at lists.llvm.org > wrote: > > >> > > > Yeah, that was gonna be my question. > > > > > > > > > > If so, my view is we should just bite the bullet and start > > > > threading > > > > post dominance through the compiler. > > > > > > > > > > (assuming anyone wants to help. I'm tackling the memoryssa > > > > updating > > > > stuff with george ATM). > > > > > >> > > > On Thu, Mar 24, 2016 at 7:04 PM, Hal Finkel < hfinkel at anl.gov > > > > > wrote: > > > > > >> > > > > [+Danny] > > > > > > > > > >> > > > > ----- Original Message ----- > > > > > > > > > >> > > > > > From: "Justin Bogner via llvm-dev" < > > > > > > llvm-dev at lists.llvm.org > > > > > > > > > > > > > > > > > > > > > > > To: "David Callahan via llvm-dev" < llvm-dev at lists.llvm.org > > > > > > > > > > > > > > > > > > > > > > > Sent: Wednesday, March 23, 2016 12:36:50 PM > > > > > > > > > > > > > > > > Subject: Re: [llvm-dev] RFC: New aggressive dead code > > > > > > elimination > > > > > > pass > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David Callahan via llvm-dev < llvm-dev at lists.llvm.org > > > > > > > writes: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a new variant of Aggressive Dead Code Elimination > > > > > > > that > > > > > > > also > > > > > > > > > > > > > > > > > removes dead branching. It is designed to minimize the > > > > > > > cost > > > > > > > of > > > > > > > > > > > > > > > > > control-dependence analysis in the common case where > > > > > > > almost > > > > > > > the > > > > > > > > > > > > > > > > > entire > > > > > > > > > > > > > > > > > program is live. It also can optionally remove dead but > > > > > > > > > > > > > > > > > may-be-infinite loops. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When enabled for –O3 (replacing current ADCE pass) and > > > > > > > removing > > > > > > > > > > > > > > > > > loops, > > > > > > > > > > > > > > > > > impact on SPEC2006 is in the noise but it impacts > > > > > > > internal > > > > > > > > > > > > > > > > > benchmarks > > > > > > > > > > > > > > > > > suites 1-2% with a comparable increase in compile time. > > > > > > > My > > > > > > > > > > > > > > > > > expectation would be to enable –O3 only until we have > > > > > > > some > > > > > > > > > > > > > > > > > experience > > > > > > > > > > > > > > > > > with cost but I suspect it should be fine –O2. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just to clarify, you're saying that both runtime and > > > > > > compile > > > > > > time > > > > > > > > > > > > > > > > impact > > > > > > > > > > > > > > > > were in the noise on SPEC, right? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What information would the community like to see about > > > > > > > such > > > > > > > a > > > > > > > > > > > > > > > > > change > > > > > > > > > > > > > > > > > before I put up a diff and (including tweaks to unit > > > > > > > tests). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure that there's much to discuss in the abstract - > > > > > > it's > > > > > > much > > > > > > > > > > > > > > > > easier to evaluate this kind of thing when there's a patch > > > > > > to > > > > > > refer > > > > > > > > > > > > > > > > to. > > > > > > > > > > > > > > > > Presumably people will want to try the patch out on their > > > > > > own > > > > > > > > > > > > > > > > internal > > > > > > > > > > > > > > > > benchmarks as well. > > > > > > > > > >> > > > > +1 > > > > > > > > > >> > > > > Does it use post-dominance information? > > > > > > > > > >> > > > > -Hal > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > david > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > LLVM Developers mailing list > > > > > > > > > > > > > > > > > llvm-dev at lists.llvm.org > > > > > > > > > > > > > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > LLVM Developers mailing list > > > > > > > > > > > > > > > > llvm-dev at lists.llvm.org > > > > > > > > > > > > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > -- > > > > > > > > > > > > > > > Hal Finkel > > > > > > > > > > > > > > > Assistant Computational Scientist > > > > > > > > > > > > > > > Leadership Computing Facility > > > > > > > > > > > > > > > Argonne National Laboratory > > > > > > > > > >> > > > _______________________________________________ > > > > > > > > > > LLVM Developers mailing list > > > > > > > > > > llvm-dev at lists.llvm.org > > > > > > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > >> > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160325/38266d8f/attachment.html>
Daniel Berlin via llvm-dev
2016-Mar-25 23:03 UTC
[llvm-dev] RFC: New aggressive dead code elimination pass
On Fri, Mar 25, 2016 at 3:43 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:> > On Mar 25, 2016, at 3:30 PM, Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Make most things update post-dominance info and preserve it. > > Our other alternative to not take up too much time seems to be invasive > surgery on how BB successors/predecessors work so they are a constant time > array. I say this because GCC recomputes post-dominators roughly 15-19 > times per compilation, and can do it about 3-5x faster than we can. All > profiling i've done basically says all our time is spent trying to get at > successors and predecessors in dominance/post-dominance respectively, which > takes basically no time in gcc, because the edge lists are an array. > > (Note that if you look at generic dominance code, like > http://www.cs.princeton.edu/~rwerneck/dominators/, it's much faster than > what we do on the same graphs. This is true even though we use the same > algorithms .....) > > Given it seems unlikely we are going to change the internal representation > anytime soon (or at least i've not seen a proposal), updating post-dom > seems the easier answer. > > > Are we talking about the basic-blocks edges only? >Yes. Only the successor and predecessors.> I'm not sure changing the IR for the BBs would be a lot more work than > preserving dominance analysis everywhere, or I am totally underestimating > one / overestimating the other? >The way "edges" work right now is that it walks the use/users lists. In the case of predecessors, it walks the user list of the bb, and sees which ones are terminator instructions, and then hands you the parent bb's of those. In the case of successor, the operand array stores it, but it requires some indirect loads per successor. The advantage to this scheme is that if you set the operand of the terminator, you've updated the edge. It requires no other work. Chandler was strongly against edge cuts not being super-fast constant time[1] If you move to edge arrays, it now requires finding and updating the terminators, unless you keep them both as use lists somehow (which are still about 1.5-2x as slow as straight arrays for dominators purposes), or always have the appropriate terminator around. In any case, it's really hard to have a case where you don't have to update some stuff on edge redirection, even if you can store stuff to do it in constant time. For example, you would have to keep an array of (bb, index in succ/pred array) and (terminators, operandno) or something similar to give you constant time cutting (because you have to update both ends, so you need to know where everything is both directions from whatever list you are looking at) if you can deal with linear time this is much easier. [1]I don't think it matters as much as he does. They don't happen that often, and even in the case of bugpoint, most blocks do not have a ton of edges, so it won't slow much down for bugpointing real programs. The significantly better cache behavior may even make up for it in practice.> -- > Mehdi > > > > > > On Thu, Mar 24, 2016 at 11:56 PM, Eric Christopher <echristo at gmail.com> > wrote: > >> What do you have in mind here? >> >> On Thu, Mar 24, 2016, 7:28 PM Daniel Berlin via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Yeah, that was gonna be my question. >>> If so, my view is we should just bite the bullet and start threading >>> post dominance through the compiler. >>> (assuming anyone wants to help. I'm tackling the memoryssa updating >>> stuff with george ATM). >>> >>> >>> >>> On Thu, Mar 24, 2016 at 7:04 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> >>>> [+Danny] >>>> >>>> ----- Original Message ----- >>>> > From: "Justin Bogner via llvm-dev" <llvm-dev at lists.llvm.org> >>>> > To: "David Callahan via llvm-dev" <llvm-dev at lists.llvm.org> >>>> > Sent: Wednesday, March 23, 2016 12:36:50 PM >>>> > Subject: Re: [llvm-dev] RFC: New aggressive dead code elimination pass >>>> > >>>> > David Callahan via llvm-dev <llvm-dev at lists.llvm.org> writes: >>>> > > Hi, >>>> > > >>>> > > I have a new variant of Aggressive Dead Code Elimination that also >>>> > > removes dead branching. It is designed to minimize the cost of >>>> > > control-dependence analysis in the common case where almost the >>>> > > entire >>>> > > program is live. It also can optionally remove dead but >>>> > > may-be-infinite loops. >>>> > > >>>> > > When enabled for –O3 (replacing current ADCE pass) and removing >>>> > > loops, >>>> > > impact on SPEC2006 is in the noise but it impacts internal >>>> > > benchmarks >>>> > > suites 1-2% with a comparable increase in compile time. My >>>> > > expectation would be to enable –O3 only until we have some >>>> > > experience >>>> > > with cost but I suspect it should be fine –O2. >>>> > >>>> > Just to clarify, you're saying that both runtime and compile time >>>> > impact >>>> > were in the noise on SPEC, right? >>>> > >>>> > > What information would the community like to see about such a >>>> > > change >>>> > > before I put up a diff and (including tweaks to unit tests). >>>> > >>>> > I'm not sure that there's much to discuss in the abstract - it's much >>>> > easier to evaluate this kind of thing when there's a patch to refer >>>> > to. >>>> > Presumably people will want to try the patch out on their own >>>> > internal >>>> > benchmarks as well. >>>> >>>> +1 >>>> >>>> Does it use post-dominance information? >>>> >>>> -Hal >>>> >>>> > >>>> > > Thanks >>>> > > david >>>> > > _______________________________________________ >>>> > > LLVM Developers mailing list >>>> > > llvm-dev at lists.llvm.org >>>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> > _______________________________________________ >>>> > LLVM Developers mailing list >>>> > llvm-dev at lists.llvm.org >>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> > >>>> >>>> -- >>>> Hal Finkel >>>> Assistant Computational Scientist >>>> Leadership Computing Facility >>>> Argonne National Laboratory >>>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > _______________________________________________ > 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/20160325/0b8e36ad/attachment.html>
Daniel Berlin via llvm-dev
2016-Mar-25 23:05 UTC
[llvm-dev] RFC: New aggressive dead code elimination pass
On Fri, Mar 25, 2016 at 3:52 PM, Hal Finkel <hfinkel at anl.gov> wrote:> > ------------------------------ > > *From: *"Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Daniel Berlin" <dberlin at dberlin.org> > *Cc: *"David Callahan via llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Friday, March 25, 2016 5:43:12 PM > *Subject: *Re: [llvm-dev] RFC: New aggressive dead code elimination pass > > > On Mar 25, 2016, at 3:30 PM, Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Make most things update post-dominance info and preserve it. > > Our other alternative to not take up too much time seems to be invasive > surgery on how BB successors/predecessors work so they are a constant time > array. I say this because GCC recomputes post-dominators roughly 15-19 > times per compilation, and can do it about 3-5x faster than we can. All > profiling i've done basically says all our time is spent trying to get at > successors and predecessors in dominance/post-dominance respectively, which > takes basically no time in gcc, because the edge lists are an array. > > (Note that if you look at generic dominance code, like > http://www.cs.princeton.edu/~rwerneck/dominators/, it's much faster than > what we do on the same graphs. This is true even though we use the same > algorithms .....) > > Given it seems unlikely we are going to change the internal representation > anytime soon (or at least i've not seen a proposal), updating post-dom > seems the easier answer. > > > Are we talking about the basic-blocks edges only? I'm not sure changing > the IR for the BBs would be a lot more work than preserving dominance > analysis everywhere, or I am totally underestimating one / overestimating > the other? > > > I'm also curious about this, especially because I'd naively think that: > > representation change == a little thinking and (potentially) a lot of > typing >It also may change space characteristics for programs with lots of edges.> preserving post dom == a lot of thinking and a little typing > > and, thus, while updating the analysis might be the *right* thing to do, > it is probably not easier (especially once you factor in the time taken to > fix bugs where we subtly get it wrong). Maybe in the long run, we should do > both? >If we try to keep constant time edge redirection, both are fairly complicated in terms of thinking :)> > -Hal > > -- > Mehdi > > > > > > On Thu, Mar 24, 2016 at 11:56 PM, Eric Christopher <echristo at gmail.com> > wrote: > >> What do you have in mind here? >> >> On Thu, Mar 24, 2016, 7:28 PM Daniel Berlin via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Yeah, that was gonna be my question. >>> If so, my view is we should just bite the bullet and start threading >>> post dominance through the compiler. >>> (assuming anyone wants to help. I'm tackling the memoryssa updating >>> stuff with george ATM). >>> >>> >>> >>> On Thu, Mar 24, 2016 at 7:04 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> >>>> [+Danny] >>>> >>>> ------------------------------ >>>> >>>> > From: "Justin Bogner via llvm-dev" <llvm-dev at lists.llvm.org> >>>> > To: "David Callahan via llvm-dev" <llvm-dev at lists.llvm.org> >>>> > Sent: Wednesday, March 23, 2016 12:36:50 PM >>>> > Subject: Re: [llvm-dev] RFC: New aggressive dead code elimination pass >>>> > >>>> > David Callahan via llvm-dev <llvm-dev at lists.llvm.org> writes: >>>> > > Hi, >>>> > > >>>> > > I have a new variant of Aggressive Dead Code Elimination that also >>>> > > removes dead branching. It is designed to minimize the cost of >>>> > > control-dependence analysis in the common case where almost the >>>> > > entire >>>> > > program is live. It also can optionally remove dead but >>>> > > may-be-infinite loops. >>>> > > >>>> > > When enabled for –O3 (replacing current ADCE pass) and removing >>>> > > loops, >>>> > > impact on SPEC2006 is in the noise but it impacts internal >>>> > > benchmarks >>>> > > suites 1-2% with a comparable increase in compile time. My >>>> > > expectation would be to enable –O3 only until we have some >>>> > > experience >>>> > > with cost but I suspect it should be fine –O2. >>>> > >>>> > Just to clarify, you're saying that both runtime and compile time >>>> > impact >>>> > were in the noise on SPEC, right? >>>> > >>>> > > What information would the community like to see about such a >>>> > > change >>>> > > before I put up a diff and (including tweaks to unit tests). >>>> > >>>> > I'm not sure that there's much to discuss in the abstract - it's much >>>> > easier to evaluate this kind of thing when there's a patch to refer >>>> > to. >>>> > Presumably people will want to try the patch out on their own >>>> > internal >>>> > benchmarks as well. >>>> >>>> +1 >>>> >>>> Does it use post-dominance information? >>>> >>>> -Hal >>>> >>>> > >>>> > > Thanks >>>> > > david >>>> > > _______________________________________________ >>>> > > LLVM Developers mailing list >>>> > > llvm-dev at lists.llvm.org >>>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> > _______________________________________________ >>>> > LLVM Developers mailing list >>>> > llvm-dev at lists.llvm.org >>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> > >>>> >>>> -- >>>> Hal Finkel >>>> Assistant Computational Scientist >>>> Leadership Computing Facility >>>> Argonne National Laboratory >>>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160325/dc429f63/attachment.html>