[LLVMdev] Counting load and stores of variables

[Nema, Ashutosh]

Are you trying to capture information in higher optimization level ?
If yes, then it will be tricky and you may not get correct information.
You should be careful with cases where load & stores are optimized by registers.

You can try address based instrument in your translation units.
Whenever you see memory accesses (i.e. load & store) instrument them to print to a file.

i.e.
address x100 accessed as store.
address x200 accessed as store.
address x100 accessed as store.
address x100 accessed as load.

Also print variable belongs to address.
i.e.
a address is x100
b address is x200.

later as a post processing step, process that file to generate consolidated report.
Sometime adding instrumentation will hurdle few optimizations and generated report
may not be the default execution flavor but it will be very closed to it.

Regards,
Ashutosh


From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of MKT
Sent: Monday, March 09, 2015 4:54 PM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Counting load and stores of variables

Hi all,
I’m working on my thesis in which I need to count the number of memory access (i.e. load and stores) of each variable of program. how can I do that? these are some approaches came to my mind :

  *   I need to know during the execution of the program how many load and store instructions are executed on a specific variable, hence simply counting static load and store instructions doesn’t help.
  *   I also cannot write an IR pass to inject some instructions to count memory accesses of variables (instrumenting) , because in IR optimization I’m not aware of what will happen in register allocation.
  *   And if I write a machine pass to inject machine instructions, I guess maybe I loose some informations( e.g. variable names) during the optimizations.

Thanks,
MohammadKazem



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