llvm dev - May 2016 - [GSoC 2016] Introduction & Feedback - Better Alias Analysis

(Just to note: the other issue i remember with CFL-AA is that it currently
causes performance loss. This is quite common when you increase precision,
because things move/change things they couldn't before, and often do so
without the natural bounds imprecision provided before :P)


On Thu, May 12, 2016 at 12:29 AM, James Molloy via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Yep, same. What's the magic rune to enable cfl-aa?
>
> James
>
> On Thu, 12 May 2016 at 05:58 Philip Reames via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On 05/11/2016 05:16 PM, George Burgess IV via llvm-dev wrote:
>>
>> > After applying the patch on r267335 and bootstrap LLVM/clang with
>> cfl-aa enabled on its own as well as behind basic-aa on an x86 machine,
I
>> ran test-suite with lit and saw no failed test cases
>>
>> Woohoo! This is great news. :D
>>
>> Awesome!
>>
>>
>> I'm not sure how closely everyone is reading the intro emails, so
we may
>> get more help if we also send a slightly more targeted "Hey, CFLAA
isn't
>> obviously broken anymore. Please help us find any other problems/please
>> report performance numbers to us," email. Whether we do that this
very
>> second, or when GSoC actually starts, is up to you.
>>
>> Once this lands in tree, I'll do a run on our codebase to see if I
see
>> anything obvious.  I suspect others can do the same.
>>
>>
>> Philip
>>
>>
>> On Wed, May 11, 2016 at 3:02 PM, Jia Chen via llvm-dev <
>> <llvm-dev at lists.llvm.org>llvm-dev at lists.llvm.org> wrote:
>>
>>> Dear LLVM community,
>>>
>>> I am a GSoC student this year working on the project of improving
alias
>>> analysis in LLVM.
>>>
>>> The proposal initially came from a discussion I had with various
devs on
>>> the mailing list some time ago [1]. The general goal of this
project is to
>>> make alias analysis (in particular, cfl-aa) "better", and
to be more
>>> concrete here is a list of objectives I had in mind:
>>>
>>> - Evaluating the current state of cfl-aa, and fix all known bugs.
>>> - Improving the precision of cfl-aa. Although flow sensitivity may
not
>>> be very helpful for LLVM in its current form, field sensitivity
should be
>>> something important and I'll definitely try to add it to
cfl-aa. Given the
>>> complexity LLVM's memory model has, my guess is that I may need
to spend
>>> most of my summer on this task.
>>> - Improving the performance of cfl-aa. (It is fairly efficient in
its
>>> current form, IMO. Further performance tuning may be needed if more
>>> features such as field sensitivity were added.)
>>> - Understanding how various clients interacts with cfl-aa, and
exploring
>>> various ways to minimize precision/performance losses caused by the
>>> interaction.
>>> - If time permits, maybe I can look at scev-aa and try to bring it
back
>>> to the compilation pipeline.
>>>
>>> I know these objectives are not as clear cut as other GSoC projects
>>> people used to have, and it is hard to come up with a clear
schedule as
>>> well as a success metric. Nevertheless even if my contributions may
seem
>>> fragmented and incremental, I felt that as long as the work is
useful to
>>> the community, it is going to be the most valuable summer I've
ever had as
>>> a student.
>>>
>>> ** Current Status **
>>>
>>> I've submitted a simple patch last week (D19776) to fix a
subtle bug in
>>> cfl-aa. After applying the patch on r267335 and bootstrap
LLVM/clang with
>>> cfl-aa enabled on its own as well as behind basic-aa on an x86
machine, I
>>> ran test-suite with lit and saw no failed test cases. I didn't
time the
>>> tests in any rigorous way, but it didn't look like cfl-aa add
very
>>> noticable performance overhead. It may be a good time, I think, to
call for
>>> people's help to test cfl-aa on their internal codebase. If
everything goes
>>> well, we should be able to safely turn on cfl-aa by default soon.
>>>
>>> Let me conclude this introduction by saying thank you for accepting
my
>>> proposal, and in particular I want to thank my mentors George and
Hal for
>>> the providing me with so much support and guidance. Please let me
know if
>>> you have any comments or suggestions.
>>>
>>> [1] http://lists.llvm.org/pipermail/llvm-dev/2016-March/096851.html
>>>
>>> --
>>> Best Regards,
>>>
>>> --
>>> Jia Chen
>>> Department of Computer Science
>>> University of Texas at Austinjchen at cs.utexas.edu
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing listllvm-dev at
lists.llvm.orghttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/84b4aec7/attachment.html>

> What's the magic rune to enable cfl-aa?
We have two magical opt flags: -use-cfl-aa and -use-cfl-aa-in-codegen :)

IIRC, both of them should cause CFLAA to be enabled as a last resort.

On Thu, May 12, 2016 at 12:38 AM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> (Just to note: the other issue i remember with CFL-AA is that it currently
> causes performance loss. This is quite common when you increase precision,
> because things move/change things they couldn't before, and often do so
> without the natural bounds imprecision provided before :P)
>
>
> On Thu, May 12, 2016 at 12:29 AM, James Molloy via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Yep, same. What's the magic rune to enable cfl-aa?
>>
>> James
>>
>> On Thu, 12 May 2016 at 05:58 Philip Reames via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On 05/11/2016 05:16 PM, George Burgess IV via llvm-dev wrote:
>>>
>>> > After applying the patch on r267335 and bootstrap LLVM/clang
with
>>> cfl-aa enabled on its own as well as behind basic-aa on an x86
machine, I
>>> ran test-suite with lit and saw no failed test cases
>>>
>>> Woohoo! This is great news. :D
>>>
>>> Awesome!
>>>
>>>
>>> I'm not sure how closely everyone is reading the intro emails,
so we may
>>> get more help if we also send a slightly more targeted "Hey,
CFLAA isn't
>>> obviously broken anymore. Please help us find any other
problems/please
>>> report performance numbers to us," email. Whether we do that
this very
>>> second, or when GSoC actually starts, is up to you.
>>>
>>> Once this lands in tree, I'll do a run on our codebase to see
if I see
>>> anything obvious.  I suspect others can do the same.
>>>
>>>
>>> Philip
>>>
>>>
>>> On Wed, May 11, 2016 at 3:02 PM, Jia Chen via llvm-dev <
>>> <llvm-dev at lists.llvm.org>llvm-dev at lists.llvm.org>
wrote:
>>>
>>>> Dear LLVM community,
>>>>
>>>> I am a GSoC student this year working on the project of
improving alias
>>>> analysis in LLVM.
>>>>
>>>> The proposal initially came from a discussion I had with
various devs
>>>> on the mailing list some time ago [1]. The general goal of this
project is
>>>> to make alias analysis (in particular, cfl-aa)
"better", and to be more
>>>> concrete here is a list of objectives I had in mind:
>>>>
>>>> - Evaluating the current state of cfl-aa, and fix all known
bugs.
>>>> - Improving the precision of cfl-aa. Although flow sensitivity
may not
>>>> be very helpful for LLVM in its current form, field sensitivity
should be
>>>> something important and I'll definitely try to add it to
cfl-aa. Given the
>>>> complexity LLVM's memory model has, my guess is that I may
need to spend
>>>> most of my summer on this task.
>>>> - Improving the performance of cfl-aa. (It is fairly efficient
in its
>>>> current form, IMO. Further performance tuning may be needed if
more
>>>> features such as field sensitivity were added.)
>>>> - Understanding how various clients interacts with cfl-aa, and
>>>> exploring various ways to minimize precision/performance losses
caused by
>>>> the interaction.
>>>> - If time permits, maybe I can look at scev-aa and try to bring
it back
>>>> to the compilation pipeline.
>>>>
>>>> I know these objectives are not as clear cut as other GSoC
projects
>>>> people used to have, and it is hard to come up with a clear
schedule as
>>>> well as a success metric. Nevertheless even if my contributions
may seem
>>>> fragmented and incremental, I felt that as long as the work is
useful to
>>>> the community, it is going to be the most valuable summer
I've ever had as
>>>> a student.
>>>>
>>>> ** Current Status **
>>>>
>>>> I've submitted a simple patch last week (D19776) to fix a
subtle bug in
>>>> cfl-aa. After applying the patch on r267335 and bootstrap
LLVM/clang with
>>>> cfl-aa enabled on its own as well as behind basic-aa on an x86
machine, I
>>>> ran test-suite with lit and saw no failed test cases. I
didn't time the
>>>> tests in any rigorous way, but it didn't look like cfl-aa
add very
>>>> noticable performance overhead. It may be a good time, I think,
to call for
>>>> people's help to test cfl-aa on their internal codebase. If
everything goes
>>>> well, we should be able to safely turn on cfl-aa by default
soon.
>>>>
>>>> Let me conclude this introduction by saying thank you for
accepting my
>>>> proposal, and in particular I want to thank my mentors George
and Hal for
>>>> the providing me with so much support and guidance. Please let
me know if
>>>> you have any comments or suggestions.
>>>>
>>>> [1]
http://lists.llvm.org/pipermail/llvm-dev/2016-March/096851.html
>>>>
>>>> --
>>>> Best Regards,
>>>>
>>>> --
>>>> Jia Chen
>>>> Department of Computer Science
>>>> University of Texas at Austinjchen at cs.utexas.edu
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing listllvm-dev at
lists.llvm.orghttp://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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/f4bc927e/attachment-0001.html>

Hi Jia-

What apps/benchmarks do you plan to use to test the performance of cfl-aa ?

-Dibyendu

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of George
Burgess IV via llvm-dev
Sent: Thursday, May 12, 2016 11:16 PM
To: James Molloy <james at jamesmolloy.co.uk>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; Jia Chen <jchen at
cs.utexas.edu>
Subject: Re: [llvm-dev] [GSoC 2016] Introduction & Feedback - Better Alias
Analysis
> What's the magic rune to enable cfl-aa?
We have two magical opt flags: -use-cfl-aa and -use-cfl-aa-in-codegen :)

IIRC, both of them should cause CFLAA to be enabled as a last resort.

On Thu, May 12, 2016 at 12:38 AM, Daniel Berlin <dberlin at
dberlin.org<mailto:dberlin at dberlin.org>> wrote:
(Just to note: the other issue i remember with CFL-AA is that it currently
causes performance loss. This is quite common when you increase precision,
because things move/change things they couldn't before, and often do so
without the natural bounds imprecision provided before :P)


On Thu, May 12, 2016 at 12:29 AM, James Molloy via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Yep, same. What's the magic rune to enable cfl-aa?

James

On Thu, 12 May 2016 at 05:58 Philip Reames via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On 05/11/2016 05:16 PM, George Burgess IV via llvm-dev
wrote:
> After applying the patch on r267335 and bootstrap LLVM/clang with cfl-aa
enabled on its own as well as behind basic-aa on an x86 machine, I ran
test-suite with lit and saw no failed test cases
Woohoo! This is great news. :D
Awesome!



I'm not sure how closely everyone is reading the intro emails, so we may get
more help if we also send a slightly more targeted "Hey, CFLAA isn't
obviously broken anymore. Please help us find any other problems/please report
performance numbers to us," email. Whether we do that this very second, or
when GSoC actually starts, is up to you.
Once this lands in tree, I'll do a run on our codebase to see if I see
anything obvious.  I suspect others can do the same.


Philip



On Wed, May 11, 2016 at 3:02 PM, Jia Chen via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Dear LLVM community,

I am a GSoC student this year working on the project of improving alias analysis
in LLVM.

The proposal initially came from a discussion I had with various devs on the
mailing list some time ago [1]. The general goal of this project is to make
alias analysis (in particular, cfl-aa) "better", and to be more
concrete here is a list of objectives I had in mind:

- Evaluating the current state of cfl-aa, and fix all known bugs.
- Improving the precision of cfl-aa. Although flow sensitivity may not be very
helpful for LLVM in its current form, field sensitivity should be something
important and I'll definitely try to add it to cfl-aa. Given the complexity
LLVM's memory model has, my guess is that I may need to spend most of my
summer on this task.
- Improving the performance of cfl-aa. (It is fairly efficient in its current
form, IMO. Further performance tuning may be needed if more features such as
field sensitivity were added.)
- Understanding how various clients interacts with cfl-aa, and exploring various
ways to minimize precision/performance losses caused by the interaction.
- If time permits, maybe I can look at scev-aa and try to bring it back to the
compilation pipeline.

I know these objectives are not as clear cut as other GSoC projects people used
to have, and it is hard to come up with a clear schedule as well as a success
metric. Nevertheless even if my contributions may seem fragmented and
incremental, I felt that as long as the work is useful to the community, it is
going to be the most valuable summer I've ever had as a student.

** Current Status **

I've submitted a simple patch last week (D19776) to fix a subtle bug in
cfl-aa. After applying the patch on r267335 and bootstrap LLVM/clang with cfl-aa
enabled on its own as well as behind basic-aa on an x86 machine, I ran
test-suite with lit and saw no failed test cases. I didn't time the tests in
any rigorous way, but it didn't look like cfl-aa add very noticable
performance overhead. It may be a good time, I think, to call for people's
help to test cfl-aa on their internal codebase. If everything goes well, we
should be able to safely turn on cfl-aa by default soon.

Let me conclude this introduction by saying thank you for accepting my proposal,
and in particular I want to thank my mentors George and Hal for the providing me
with so much support and guidance. Please let me know if you have any comments
or suggestions.

[1] http://lists.llvm.org/pipermail/llvm-dev/2016-March/096851.html


--

Best Regards,



--

Jia Chen

Department of Computer Science

University of Texas at Austin

jchen at cs.utexas.edu<mailto:jchen at cs.utexas.edu>

_______________________________________________
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



_______________________________________________

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

_______________________________________________
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

_______________________________________________
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160513/0d93852b/attachment.html>