Displaying 20 results from an estimated 20000 matches similar to: "[GSoC 2016] Introduction & Feedback - Better Alias Analysis"
2016 May 12
2
[GSoC 2016] Introduction & Feedback - Better Alias Analysis
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
2016 May 12
2
[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,
2016 Mar 22
0
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
2016 Mar 22
4
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
2016 May 19
1
Testing CFL alias analysis
Hi Geoff,
Thank you so much for the effort!
It's good to hear that cfl-aa didn't break anything. However, the fact
that it doesn't quite affect code generation is also concerning. I'll
definitely look into the issue.
On 05/19/2016 02:03 PM, Geoff Berry wrote:
> Hi Jia,
>
> We did some testing with CFL-AA enabled on an aarch64 OoO target on the
> llvm test-suite and
2016 May 16
2
Testing CFL alias analysis
Hello everyone,
If you've read through my previous introduction email
(http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html), you can
safely ignore this message.
The short story is: CFL-AA does not seem to be broken anymore. Please
try it out and help us find more bugs / performance issues if switching
to it in the future sounds interesting to you.
Here are more backgrounds: I
2016 Aug 26
3
CFLAA
Hi David,
I am the one who's responsible for CFLAA's refactoring in the summer.
I've sent out another email on llvm-dev, and you can find more about my
work in my GSoC final report.
I think it is fantastic that you have done such an interesting work.
I'll definitely try to help getting the code reviewed and merged in the
current. After a quick glance at your patch, it seems
2016 Mar 21
2
Existing studies on the benefits of pointer analysis
----- Original Message -----
> 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,
2016 Mar 21
6
Existing studies on the benefits of pointer analysis
Hi Daniel,
On 03/21/2016 11:05 AM, Daniel Berlin wrote:
>
>
> On Tue, Mar 15, 2016 at 1:37 PM, Jia Chen via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
> Dear llvm devs,
>
> tl;dr: What prevents llvm from switching to a fancier pointer
> analysis?
>
>
> Nothing.
>
>
> Currently,
2016 Mar 21
0
Existing studies on the benefits of pointer analysis
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
2016 Mar 21
2
Existing studies on the benefits of pointer analysis
> It is merely a demand-driven way of implementing existing
> analyses, by extending those algorithms to track additional
> "pointed-to-by" information. Laziness may help with the running
> time of the cfl analysis when only partial points-to info is
> needed, but if the client wants to do a whole-program analysis and
> require whole-program
2016 Aug 26
2
[GSoC] Final project report on CFL-AA
Dear LLVM devs,
My GSoC project this year is about alias analysis, and I wrote a short
article describing what I've done during the summer:
https://github.com/grievejia/GSoC2016/raw/master/writeup.pdf
In the report you can find an overview of what the current status of
CFL-AA. There are also some numbers in the end, but please take those
numbers with a grain of salt as they were rather
2016 Mar 21
2
Existing studies on the benefits of pointer analysis
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.
The
2016 Mar 26
2
Existing studies on the benefits of pointer analysis
>
>
>
> I’m still a big fan of context sensitive, flow insensitive, unification
> based models.
>
CFL can emulate this in the same time bound.
> Contrary to your claim, context sensitivity *is* useful for mod-ref
> analysis, e.g. “can I hoist a load across this call”? Context sensitivity
> improves the precision of the mod/ref set of the call.
>
>
-Chris
>
2016 Mar 21
1
Existing studies on the benefits of pointer analysis
> You can solve andersens and steengaards and everything else using
> standard dataflow solvers, and that's an implementation strategy, but
> it will be really slow.
>
> Part of the tradeoff is how fast something runs, and approaches that
> are orders of magnitude faster often change the calculus of what
> people do. For example, before hardekopf's work, andersens
2016 Jun 21
2
[GSoC 2016] Better Alias Analysis By Default - Mid Term Summary
Dear LLVM Community,
This is a brief summary of what I've done so far for CFL-AA, and what I
plan to do next.
tl;dr: CFL-AA is getting saner. Low-hanging fruits on its improvement
have almost been picked up. I can either make CFL-AA more precise (with
certain performance cost), or teach other passes to capitalize on CFL-AA
better as the next step. Comments and suggestions are more than
2016 Mar 26
0
Existing studies on the benefits of pointer analysis
On 03/25/2016 08:26 PM, Daniel Berlin wrote:
>
> Yeah.
> It depends entirely on your goal. In reality, often what you really
> want is something to say "hey, i've got this pointer over here, and i
> really want to hoist it up here. Do something, tell me if that is
> possible".
>
And this is one motivation of my current research: how can various
precision
2016 Mar 15
5
Existing studies on the benefits of pointer analysis
Dear llvm devs,
tl;dr: What prevents llvm from switching to a fancier pointer analysis?
Currently, there exists a variety of general-purpose alias analyses in
the LLVM codebase: basic-aa, globalsmodref-aa, tbaa, scev-aa, and
cfl-aa. However, only the first three are actually turned on when
invoking clang with -O2 or -O3 (please correct me if I'm wrong about this).
If one looks at
2016 Mar 25
1
[GSoC 2016] Proposal: CFL-AA by default
Oops thanks for the reminder. I did use another email address and am
terribly sorry for it.
Let me just post the link:
https://docs.google.com/document/d/1Kvepb-v5Ta8ug_lLK1kZeexPNlpvj62K5iIF0fMuLyM/edit?usp=sharing
On 03/25/2016 11:44 AM, John Criswell wrote:
> Dear Jia,
>
> I don't see your proposal in the system. What is the title of your
> proposal, and under what email
2016 Mar 23
2
[GSoC 2016] Proposal: CFL-AA by default
Dear llvm devs,
Based on an earlier discussion about existing pointer analyses in LLVM,
I quickly hacked up a GSoC proposal on enabling cfl-aa by default.
The decision to write it was made two days before the application
deadline, hence the writing quality may not be very satisfactory: the
background section could be less verbose, and the implementation section
could be more formal. Also it