Displaying 7 results from an estimated 7 matches for "tryinterproceduralanalysis".
2016 May 12
2
Deleting function IR after codegen
...tion bar(), and bar() calls foo().
3. During (2), we make an AA query on instructions in bar(), which have MMOs with IR Values in bar()
4. CFL-AA is reached and does not have a cached graph for bar(), so it builds one
5. While building the graph for bar(), it reaches the call to foo(), and calls tryInterproceduralAnalysis
6. CFL-AA does not have a cached graph for foo(), so tryInterproceduralAnalysis triggers one to be constructed
7. But foo() is now empty, and so has trivial aliasing properties
8. We return an incorrect AA result when compiling bar()
-Hal
> -Chandler
> On Tue, Mar 8, 2016 at 1:16 PM Q...
2016 Mar 08
3
Deleting function IR after codegen
> On Mar 8, 2016, at 11:50 AM, Eric Christopher <echristo at gmail.com> wrote:
>
>
>
>
> I could attach a patch, but first i’d really like to know if anyone is fundamentally opposed to this.
>
>
> Not necessarily. I think that any information that isn't being serialized in MI right now for a function could be as well. Definitely something for GlobalISel
2015 Mar 15
4
[LLVMdev] [GSoC] Applying for GSoC 2015
Hello Daniel,
Thank you for your comments and sorry for my mistakes, I'll revise them.
And I'll for sure read the paper you mentioned and survey the recent
researches before deciding the implementation technique.
To George:
May I know the exact plan of your attempt for making cfl-aa interprocedural?
I do think that this is the most valuable part of my proposal, but that
makes no sense to
2015 Mar 16
2
[LLVMdev] [GSoC] Applying for GSoC 2015
...ate is downloaded at
http://www.latextemplates.com/template/large-colored-title-article.
Once again, thank you for your time!
On 16 March 2015 at 02:58, George Burgess IV <george.burgess.iv at gmail.com>
wrote:
> CFLAA already has some basic interprocedural analysis built in (see:
> tryInterproceduralAnalysis; it basically boils down to CFLAA grabbing the
> StratifiedSets for each function call and unifying sets based off of that
> instead of unifying everything ever). The only real changes I had in mind
> for it were:
>
> - Adding context sensitivity (which kind of requires adding contex...
2015 Jan 26
0
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
Inline
George
> On Jan 26, 2015, at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
> George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places?
Will do. :)
> FWIW, my current list of CFLAA issues is:
>
> 1. Unknown values (results from ptrtoint, incoming
2015 Jan 26
2
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
George, given that, can you just build constexpr handling (it's not as easy
as you think) as a separate funciton and have it use it in the right places?
FWIW, my current list of CFLAA issues is:
1. Unknown values (results from ptrtoint, incoming pointers, etc) are not
treated as unknown. These should be done through graph edge (so that they
can be one way, otherwise, you will unify
2015 Jan 30
2
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
...ocB.Ptr)) {
return MayAlias;
}
@@ -456,10 +459,11 @@ public:
template <typename InstT> void visitCallLikeInst(InstT &Inst) {
SmallVector<Function *, 4> Targets;
if (getPossibleTargets(&Inst, Targets)) {
+ auto InitialSize = Output.size();
if (tryInterproceduralAnalysis(Targets, &Inst, Inst.arg_operands()))
return;
// Cleanup from interprocedural analysis
- Output.clear();
+ Output.erase(Output.begin()+InitialSize, Output.end());
}
for (Value *V : Inst.arg_operands())
@@ -720,6 +724,22 @@ static void argsToEdges(CFLAliasAn...