llvm dev - Mar 2016 - Existing studies on the benefits of pointer analysis

It's found more and more like "get CFL-AA turned on by default"
might be
a viable GSoC project for the right student.  It would require someone 
with existing knowledge of AA and a willingness to debug nasty problems, 
but it sounds like there's definitely interest in the community in 
seeing this happen.

If the student finished early (unlikely), they could start on SCEV-AA as 
well.

Philip

On 03/21/2016 01:10 PM, George Burgess IV via llvm-dev
wrote:
> As of late-August 2015, putting CFL-AA behind BasicAA caused 
> miscompiles when trying to bootstrap Clang/LLVM, yeah. It didn't seem 
> that there were many new errors (I think it caused ~10 tests to fail, 
> where fail = either segv or produce the wrong output), but it did end 
> up breaking things. I don't recall if standalone CFL-AA causes 
> miscompiles, but I highly doubt the breakages I observed were 
> BasicAA's fault.
>
> WRT speed, `time make -j14` on my box (6c/12t) didn't show a 
> meaningful increase in compile time when CFL-AA gets enabled (read: it 
> got lost in the noise). So, I agree that it's probably fast enough at 
> the moment; if we want to enhance it, we should focus on making it 
> bootstrap clang+LLVM/making it more accurate.
>
> On Mon, Mar 21, 2016 at 12:26 PM, Hal Finkel <hfinkel at anl.gov 
> <mailto:hfinkel at anl.gov>> wrote:
>
>
>    
------------------------------------------------------------------------
>
>         *From: *"Daniel Berlin via llvm-dev" <llvm-dev at
lists.llvm.org
>         <mailto:llvm-dev at lists.llvm.org>>
>         *To: *"Renato Golin" <renato.golin at linaro.org
>         <mailto:renato.golin at linaro.org>>, "George Burgess
IV"
>         <george.burgess.iv at gmail.com <mailto:george.burgess.iv at
gmail.com>>
>         *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org
>         <mailto:llvm-dev at lists.llvm.org>>, "Jia Chen"
>         <jchen at cs.utexas.edu <mailto:jchen at
cs.utexas.edu>>
>         *Sent: *Monday, March 21, 2016 2:07:44 PM
>         *Subject: *Re: [llvm-dev] Existing studies on the benefits of
>         pointer analysis
>
>
>
>         On Mon, Mar 21, 2016 at 12:05 PM, Renato Golin
>         <renato.golin at linaro.org <mailto:renato.golin at
linaro.org>> wrote:
>
>             On 21 March 2016 at 18:59, Daniel Berlin
>             <dberlin at dberlin.org <mailto:dberlin at
dberlin.org>> wrote:
>             > Which is why i've never mentioned it or used it in the
>             community ;)
>
>             Makes sense. :)
>
>
>             > I would rather see someone spend their time getting
>             SCEV-AA on by default or
>             > CFL-AA on by default than doing another evaluation.
>
>             But those may not be simple enough for a GSOC, that's why
>             I mentioned it.
>
>
>         CFL-AA should just be fixing performance regressions, and
>         maybe a little bug fixing, which is hopefully easy enough. 
>         It's already fast enough as a pass.
>
>
>     My understanding from George is that there are self-hosting
>     miscompiles if you disable all AA except for CFL-AA. This is what
>     is preventing us from enabling it by default. George, is that right?
>
>      -Hal
>
>
>         SCEV-AA would be harder (must make SCEV-AA faster).
>
>             The analysis could not only get us a birds view of the
>             problem ahead,
>             but also introduce new developers to AA, which would make
>             their future
>             work on SCEV-AA or CFL-AA easier. Kind of a teaching tool
>             to get more
>             AA-savvy people.
>
>
>         Sure.
>
>
>             cheers,
>             --renato
>
>
>
>         _______________________________________________
>         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
>
>
>
>
>     -- 
>     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/2df63c47/attachment.html>

FWIW, I'd be happy to help mentoring such a project if a student is
interested.

During the last LLVM Dev Meeting (the US one), I think better AA was number one
in the list of requested features during the BoF on "Sophisticated Program
Analysis on LLVM IR"  (
http://devmtg15.llvm.org/event/4VNY/sophisticated-program-analysis-on-llvm-ir ).
CC John, I don't remember if there was a summary of the BoF posted online.

-- 
Mehdi

> On Mar 22, 2016, at 11:55 AM, Philip Reames via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> It's found more and more like "get CFL-AA turned on by
default" might be a viable GSoC project for the right student.  It would
require someone with existing knowledge of AA and a willingness to debug nasty
problems, but it sounds like there's definitely interest in the community in
seeing this happen.
> 
> If the student finished early (unlikely), they could start on SCEV-AA as
well.
> 
> Philip
> 
> On 03/21/2016 01:10 PM, George Burgess IV via llvm-dev wrote:
>> As of late-August 2015, putting CFL-AA behind BasicAA caused
miscompiles when trying to bootstrap Clang/LLVM, yeah. It didn't seem that
there were many new errors (I think it caused ~10 tests to fail, where fail =
either segv or produce the wrong output), but it did end up breaking things. I
don't recall if standalone CFL-AA causes miscompiles, but I highly doubt the
breakages I observed were BasicAA's fault.
>> 
>> WRT speed, `time make -j14` on my box (6c/12t) didn't show a
meaningful increase in compile time when CFL-AA gets enabled (read: it got lost
in the noise). So, I agree that it's probably fast enough at the moment; if
we want to enhance it, we should focus on making it bootstrap clang+LLVM/making
it more accurate.
>> 
>> On Mon, Mar 21, 2016 at 12:26 PM, Hal Finkel <hfinkel at anl.gov
<mailto:hfinkel at anl.gov>> wrote:
>> 
>> From: "Daniel Berlin via llvm-dev" < <mailto:llvm-dev
at lists.llvm.org>llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>> To: "Renato Golin" < <mailto:renato.golin at
linaro.org>renato.golin at linaro.org <mailto:renato.golin at
linaro.org>>, "George Burgess IV" <george.burgess.iv at
gmail.com <mailto:george.burgess.iv at gmail.com>>
>> Cc: "llvm-dev" <llvm-dev at lists.llvm.org
<mailto:llvm-dev at lists.llvm.org>>, "Jia Chen" <jchen at
cs.utexas.edu <mailto:jchen at cs.utexas.edu>>
>> Sent: Monday, March 21, 2016 2:07:44 PM
>> Subject: Re: [llvm-dev] Existing studies on the benefits of pointer
analysis
>> 
>> 
>> 
>> On Mon, Mar 21, 2016 at 12:05 PM, Renato Golin <
<mailto:renato.golin at linaro.org>renato.golin at linaro.org
<mailto:renato.golin at linaro.org>> wrote:
>> On 21 March 2016 at 18:59, Daniel Berlin <dberlin at dberlin.org
<mailto:dberlin at dberlin.org>> wrote:
>> > Which is why i've never mentioned it or used it in the
community ;)
>> 
>> Makes sense. :)
>> 
>> 
>> > I would rather see someone spend their time getting SCEV-AA on by
default or
>> > CFL-AA on by default than doing another evaluation.
>> 
>> But those may not be simple enough for a GSOC, that's why I
mentioned it.
>> 
>> 
>> CFL-AA should just be fixing performance regressions, and maybe a
little bug fixing, which is hopefully easy enough.  It's already fast enough
as a pass.
>> 
>> My understanding from George is that there are self-hosting miscompiles
if you disable all AA except for CFL-AA. This is what is preventing us from
enabling it by default. George, is that right?
>> 
>>  -Hal
>> 
>> SCEV-AA would be harder (must make SCEV-AA faster).
>> 
>> The analysis could not only get us a birds view of the problem ahead,
>> but also introduce new developers to AA, which would make their future
>> work on SCEV-AA or CFL-AA easier. Kind of a teaching tool to get more
>> AA-savvy people.
>> 
>> Sure.  
>> 
>> cheers,
>> --renato
>> 
>> 
>> _______________________________________________
>> 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/20160322/c8a2a47d/attachment.html>

It's something that I am certainly interested in and qualified to do.

However, the way I read Daniel's reply in this thread is: "LLVM, in its
current form, is unlikely to benefit from a more precise aa". He did 
mention that cfl-aa is "more understandable and maintainable", and is 
"fast enough", but nothing is said about the benefits. There was some 
discussions I could find back in 2014, which basically says that cfl-aa 
offers no significant improvement in performance. Things may got greatly 
improved since then, yet it is not clear to me what the current 
situation is.

With the benefits being unclear a GSoC proposal on this topic may not 
look motivated enough.

On 03/22/2016 01:55 PM, Philip Reames wrote:
> It's found more and more like "get CFL-AA turned on by
default" might
> be a viable GSoC project for the right student.  It would require 
> someone with existing knowledge of AA and a willingness to debug nasty 
> problems, but it sounds like there's definitely interest in the 
> community in seeing this happen.
>
> If the student finished early (unlikely), they could start on SCEV-AA 
> as well.
>
> Philip
>
> On 03/21/2016 01:10 PM, George Burgess IV via llvm-dev wrote:
>> As of late-August 2015, putting CFL-AA behind BasicAA caused 
>> miscompiles when trying to bootstrap Clang/LLVM, yeah. It didn't
seem
>> that there were many new errors (I think it caused ~10 tests to fail, 
>> where fail = either segv or produce the wrong output), but it did end 
>> up breaking things. I don't recall if standalone CFL-AA causes 
>> miscompiles, but I highly doubt the breakages I observed were 
>> BasicAA's fault.
>>
>> WRT speed, `time make -j14` on my box (6c/12t) didn't show a 
>> meaningful increase in compile time when CFL-AA gets enabled (read: 
>> it got lost in the noise). So, I agree that it's probably fast
enough
>> at the moment; if we want to enhance it, we should focus on making it 
>> bootstrap clang+LLVM/making it more accurate.
>>
>> On Mon, Mar 21, 2016 at 12:26 PM, Hal Finkel <hfinkel at anl.gov 
>> <mailto:hfinkel at anl.gov>> wrote:
>>
>>
>>    
------------------------------------------------------------------------
>>
>>         *From: *"Daniel Berlin via llvm-dev" <llvm-dev at
lists.llvm.org>
>>         *To: *"Renato Golin" <renato.golin at
linaro.org>, "George
>>         Burgess IV" <george.burgess.iv at gmail.com
>>         <mailto:george.burgess.iv at gmail.com>>
>>         *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org
>>         <mailto:llvm-dev at lists.llvm.org>>, "Jia
Chen"
>>         <jchen at cs.utexas.edu <mailto:jchen at
cs.utexas.edu>>
>>         *Sent: *Monday, March 21, 2016 2:07:44 PM
>>         *Subject: *Re: [llvm-dev] Existing studies on the benefits of
>>         pointer analysis
>>
>>
>>
>>         On Mon, Mar 21, 2016 at 12:05 PM, Renato Golin
>>         <renato.golin at linaro.org> wrote:
>>
>>             On 21 March 2016 at 18:59, Daniel Berlin
>>             <dberlin at dberlin.org <mailto:dberlin at
dberlin.org>> wrote:
>>             > Which is why i've never mentioned it or used it in
the
>>             community ;)
>>
>>             Makes sense. :)
>>
>>
>>             > I would rather see someone spend their time getting
>>             SCEV-AA on by default or
>>             > CFL-AA on by default than doing another evaluation.
>>
>>             But those may not be simple enough for a GSOC, that's
why
>>             I mentioned it.
>>
>>
>>         CFL-AA should just be fixing performance regressions, and
>>         maybe a little bug fixing, which is hopefully easy enough. 
>>         It's already fast enough as a pass.
>>
>>
>>     My understanding from George is that there are self-hosting
>>     miscompiles if you disable all AA except for CFL-AA. This is what
>>     is preventing us from enabling it by default. George, is that
right?
>>
>>      -Hal
>>
>>
>>         SCEV-AA would be harder (must make SCEV-AA faster).
>>
>>             The analysis could not only get us a birds view of the
>>             problem ahead,
>>             but also introduce new developers to AA, which would make
>>             their future
>>             work on SCEV-AA or CFL-AA easier. Kind of a teaching tool
>>             to get more
>>             AA-savvy people.
>>
>>
>>         Sure.
>>
>>
>>             cheers,
>>             --renato
>>
>>
>>
>>         _______________________________________________
>>         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
>>
>>
>>
>>
>>     -- 
>>     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
>
-- 
Best Regards,

--
Jia Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/8124ef95/attachment.html>

No pointer analysis will show any benefits until it is on by default and
tuning starts :)

or everything is tuned and then it's turned on, whichever way you want to
do it.



On Tue, Mar 22, 2016 at 2:33 PM, Jia Chen <jchen at cs.utexas.edu> wrote:
> It's something that I am certainly interested in and qualified to do.
>
> However, the way I read Daniel's reply in this thread is: "LLVM,
in its
> current form, is unlikely to benefit from a more precise aa". He did
> mention that cfl-aa is "more understandable and maintainable",
and is "fast
> enough", but nothing is said about the benefits. There was some
discussions
> I could find back in 2014, which basically says that cfl-aa offers no
> significant improvement in performance. Things may got greatly improved
> since then, yet it is not clear to me what the current situation is.
>
> With the benefits being unclear a GSoC proposal on this topic may not look
> motivated enough.
>
>
> On 03/22/2016 01:55 PM, Philip Reames wrote:
>
> It's found more and more like "get CFL-AA turned on by
default" might be a
> viable GSoC project for the right student.  It would require someone with
> existing knowledge of AA and a willingness to debug nasty problems, but it
> sounds like there's definitely interest in the community in seeing this
> happen.
>
> If the student finished early (unlikely), they could start on SCEV-AA as
> well.
>
> Philip
>
> On 03/21/2016 01:10 PM, George Burgess IV via llvm-dev wrote:
>
> As of late-August 2015, putting CFL-AA behind BasicAA caused miscompiles
> when trying to bootstrap Clang/LLVM, yeah. It didn't seem that there
were
> many new errors (I think it caused ~10 tests to fail, where fail = either
> segv or produce the wrong output), but it did end up breaking things. I
> don't recall if standalone CFL-AA causes miscompiles, but I highly
doubt
> the breakages I observed were BasicAA's fault.
>
> WRT speed, `time make -j14` on my box (6c/12t) didn't show a meaningful
> increase in compile time when CFL-AA gets enabled (read: it got lost in the
> noise). So, I agree that it's probably fast enough at the moment; if we
> want to enhance it, we should focus on making it bootstrap
> clang+LLVM/making it more accurate.
>
> On Mon, Mar 21, 2016 at 12:26 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
>
>>
>> ------------------------------
>>
>> *From: *"Daniel Berlin via llvm-dev" < <llvm-dev at
lists.llvm.org>
>> llvm-dev at lists.llvm.org>
>> *To: *"Renato Golin" < <renato.golin at
linaro.org>renato.golin at linaro.org>,
>> "George Burgess IV" <george.burgess.iv at gmail.com>
>> *Cc: *"llvm-dev" < <llvm-dev at
lists.llvm.org>llvm-dev at lists.llvm.org>,
>> "Jia Chen" <jchen at cs.utexas.edu>
>> *Sent: *Monday, March 21, 2016 2:07:44 PM
>> *Subject: *Re: [llvm-dev] Existing studies on the benefits of pointer
>> analysis
>>
>>
>>
>> On Mon, Mar 21, 2016 at 12:05 PM, Renato Golin <renato.golin at
linaro.org>
>> wrote:
>>
>>> On 21 March 2016 at 18:59, Daniel Berlin <dberlin at
dberlin.org> wrote:
>>> > Which is why i've never mentioned it or used it in the
community ;)
>>>
>>> Makes sense. :)
>>>
>>>
>>> > I would rather see someone spend their time getting SCEV-AA on
by
>>> default or
>>> > CFL-AA on by default than doing another evaluation.
>>>
>>> But those may not be simple enough for a GSOC, that's why I
mentioned it.
>>>
>>>
>> CFL-AA should just be fixing performance regressions, and maybe a
little
>> bug fixing, which is hopefully easy enough.  It's already fast
enough as a
>> pass.
>>
>>
>> My understanding from George is that there are self-hosting miscompiles
>> if you disable all AA except for CFL-AA. This is what is preventing us
from
>> enabling it by default. George, is that right?
>>
>>  -Hal
>>
>>
>> SCEV-AA would be harder (must make SCEV-AA faster).
>>
>> The analysis could not only get us a birds view of the problem ahead,
>>> but also introduce new developers to AA, which would make their
future
>>> work on SCEV-AA or CFL-AA easier. Kind of a teaching tool to get
more
>>> AA-savvy people.
>>>
>>
>> Sure.
>>
>>>
>>> cheers,
>>> --renato
>>>
>>
>>
>> _______________________________________________
>> 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 listllvm-dev at
lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Best Regards,
>
> --
> Jia Chen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/c744190e/attachment.html>

----- Original Message -----
> From: "Jia Chen via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Philip Reames" <listmail at philipreames.com>, dberlin
at dberlin.org
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Tuesday, March 22, 2016 4:33:34 PM
> Subject: Re: [llvm-dev] Existing studies on the benefits of pointer
analysis
> 
> 
> It's something that I am certainly interested in and qualified to do.
> 
> However, the way I read Daniel's reply in this thread is: "LLVM,
in
> its current form, is unlikely to benefit from a more precise aa". He
> did mention that cfl-aa is "more understandable and
maintainable",
> and is "fast enough", but nothing is said about the benefits.
There
> was some discussions I could find back in 2014, which basically says
> that cfl-aa offers no significant improvement in performance. Things
> may got greatly improved since then, yet it is not clear to me what
> the current situation is.
> 
> With the benefits being unclear a GSoC proposal on this topic may not
> look motivated enough.
> 
I think there's wide interest in getting CFL-AA into a usable state. As I
recall, the percentage of noalias results during self hosting went up by a huge
amount (for example). More noalias results obviously does not guarantee better
code performance (the performance could even be worse because of register
allocation / scheduling deficiencies). Nevertheless, we'll never do better
if we're hamstrung by poor aliasing results.

Moreover, we currently rely heavily on BasicAA, which is a huge collection of
local heuristics that catches many things, but is quite slow. It is slow because
it needs to do local recursive walks for each pointwise query. If getting
CFL-AA, in addition to increasing precision, provides us with a path away from
our current BasicAA design toward something with better complexity, that's a
definite win.

 -Hal
> 
> On 03/22/2016 01:55 PM, Philip Reames wrote:
> 
> 
> It's found more and more like "get CFL-AA turned on by
default" might
> be a viable GSoC project for the right student. It would require
> someone with existing knowledge of AA and a willingness to debug
> nasty problems, but it sounds like there's definitely interest in
> the community in seeing this happen.
> 
> If the student finished early (unlikely), they could start on SCEV-AA
> as well.
> 
> Philip
> 
> 
> On 03/21/2016 01:10 PM, George Burgess IV via llvm-dev wrote:
> 
> 
> 
> 
> As of late-August 2015, putting CFL-AA behind BasicAA caused
> miscompiles when trying to bootstrap Clang/LLVM, yeah. It didn't
> seem that there were many new errors (I think it caused ~10 tests to
> fail, where fail = either segv or produce the wrong output), but it
> did end up breaking things. I don't recall if standalone CFL-AA
> causes miscompiles, but I highly doubt the breakages I observed were
> BasicAA's fault.
> 
> 
> WRT speed, `time make -j14` on my box (6c/12t) didn't show a
> meaningful increase in compile time when CFL-AA gets enabled (read:
> it got lost in the noise). So, I agree that it's probably fast
> enough at the moment; if we want to enhance it, we should focus on
> making it bootstrap clang+LLVM/making it more accurate.
> 
> 
> On Mon, Mar 21, 2016 at 12:26 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> From: "Daniel Berlin via llvm-dev" < llvm-dev at
lists.llvm.org >
> To: "Renato Golin" < renato.golin at linaro.org >,
"George Burgess IV" <
> george.burgess.iv at gmail.com >
> Cc: "llvm-dev" < llvm-dev at lists.llvm.org >, "Jia
Chen" <
> jchen at cs.utexas.edu >
> Sent: Monday, March 21, 2016 2:07:44 PM
> Subject: Re: [llvm-dev] Existing studies on the benefits of pointer
> analysis
> 
> 
> 
> 
> 
> 
> On Mon, Mar 21, 2016 at 12:05 PM, Renato Golin <
> renato.golin at linaro.org > wrote:
> 
> 
> On 21 March 2016 at 18:59, Daniel Berlin < dberlin at dberlin.org >
> wrote:
> > Which is why i've never mentioned it or used it in the community
;)
> 
> Makes sense. :)
> 
> 
> > I would rather see someone spend their time getting SCEV-AA on by
> > default or
> > CFL-AA on by default than doing another evaluation.
> 
> But those may not be simple enough for a GSOC, that's why I mentioned
> it.
> 
> 
> 
> 
> CFL-AA should just be fixing performance regressions, and maybe a
> little bug fixing, which is hopefully easy enough. It's already fast
> enough as a pass.
> My understanding from George is that there are self-hosting
> miscompiles if you disable all AA except for CFL-AA. This is what is
> preventing us from enabling it by default. George, is that right?
> 
> -Hal
> 
> 
> 
> 
> 
> 
> 
> 
> SCEV-AA would be harder (must make SCEV-AA faster).
> 
> 
> 
> The analysis could not only get us a birds view of the problem ahead,
> but also introduce new developers to AA, which would make their
> future
> work on SCEV-AA or CFL-AA easier. Kind of a teaching tool to get more
> AA-savvy people.
> 
> 
> 
> Sure.
> 
> 
> cheers,
> --renato
> 
> 
> _______________________________________________
> 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
> --
> Best Regards,
> 
> --
> Jia Chen
> 
> _______________________________________________
> 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