Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design multiple approaches to attach information to CFG or Values #5

Open
michkot opened this issue Mar 8, 2017 · 5 comments
Open
Assignees
Labels

Comments

@michkot
Copy link
Member

michkot commented Mar 8, 2017

Design several possible ways how to attach information to instructions or values.
Present motivation for this is dead/live variable analysis - results of such an analysis could be precomputed and assigned either to CfgNodes (instructions) or to FrontendIds (values / SSA registers).

Info sources:
https://github.com/kdudka/predator/blob/master/cl/killer.cc
http://llvm.org/docs/doxygen/html/LiveVariables_8h_source.html
http://llvm.org/docs/doxygen/html/classllvm_1_1LiveVariables.html

@michkot michkot added the design label Mar 8, 2017
@michkot michkot assigned CharvN and michkot and unassigned CharvN Mar 8, 2017
@michkot
Copy link
Member Author

michkot commented Mar 14, 2017

From meeting 14.03.2017:
It is some kind of "information bag" attached to CFG nodes.
Annotation should be both framework provided/predefined and analysis specific

@michkot suggests something like Type->instance of Type info dictionary.

// sample code for non-sharing annotations 
info.Get<MySpecialCfgAttribute>();
info.Set<MySpecialCfgAttribute>(uptr<MySpecialCfgAttribute>&& element); //ptr constructor
info.Set<MySpecialCfgAttribute>(args&&..); //emplace constructor
info.Set<MySpecialCfgAttribute>(MySpecialCfgAttribute&&) //move constructor
// sample for sharing annotations
info.SetShared<MySpecialCfgAttribute>(const MySpecialCfgAttribute&) //store ref/ptr 
// both could be mixed if needed (there is an endless amount of ways how to implement this) 

@peringer suggests mapping custom keys to 0-based indexes, and then using those indexes under the hood. Annotation storage could be small_vector<uptr>
my comment: registration of annotation types could

  1. be done manually in some Init function
  2. happen at start-up time (linking-safe, static instance of class, constructor magic)
  3. ... other ideas?

@tfiedor also suggested something similar to those ideas, but i forgot what it was...

Notes:

  • Base class is needed, because it provides interface with virtual destructor and/or deleter
  • uptr<> stands for std::unique_ptr<>

I believe this is a critical feature of Angie framework and I would like to make it right and call for a wider discussion here or at slack.

@michkot michkot modified the milestones: Feature complete framework, SMG based analysis with list segment abtraction Mar 14, 2017
@peringer
Copy link
Collaborator

maybe we can use the access method: AttrBasePtr p = node.annotation(indexEnum4myAppendix);

@michkot
Copy link
Member Author

michkot commented Mar 16, 2017 via email

@peringer
Copy link
Collaborator

I created proof of concept code - see sarka:/home/local/0-angie/angie-test2.cc

@michkot
Copy link
Member Author

michkot commented Mar 20, 2017

I've created a gist (github snippet) with the code:
https://gist.github.com/michkot/971ddd5e5c53d7113660d8c0d4dc94f4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants