Mercurial > hg > CbC > CbC_llvm
comparison docs/AliasAnalysis.rst @ 148:63bd29f05246
merged
author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
---|---|
date | Wed, 14 Aug 2019 19:46:37 +0900 |
parents | c2174574ed3a |
children |
comparison
equal
deleted
inserted
replaced
146:3fc4d5c3e21e | 148:63bd29f05246 |
---|---|
387 keep an AliasAnalysis consistent, however there's no way for a pass to declare | 387 keep an AliasAnalysis consistent, however there's no way for a pass to declare |
388 in its ``getAnalysisUsage`` that it does so. Some passes attempt to use | 388 in its ``getAnalysisUsage`` that it does so. Some passes attempt to use |
389 ``AU.addPreserved<AliasAnalysis>``, however this doesn't actually have any | 389 ``AU.addPreserved<AliasAnalysis>``, however this doesn't actually have any |
390 effect. | 390 effect. |
391 | 391 |
392 ``AliasAnalysisCounter`` (``-count-aa``) are implemented as ``ModulePass`` | |
393 classes, so if your alias analysis uses ``FunctionPass``, it won't be able to | |
394 use these utilities. If you try to use them, the pass manager will silently | |
395 route alias analysis queries directly to ``BasicAliasAnalysis`` instead. | |
396 | |
397 Similarly, the ``opt -p`` option introduces ``ModulePass`` passes between each | 392 Similarly, the ``opt -p`` option introduces ``ModulePass`` passes between each |
398 pass, which prevents the use of ``FunctionPass`` alias analysis passes. | 393 pass, which prevents the use of ``FunctionPass`` alias analysis passes. |
399 | 394 |
400 The ``AliasAnalysis`` API does have functions for notifying implementations when | 395 The ``AliasAnalysis`` API does have functions for notifying implementations when |
401 values are deleted or copied, however these aren't sufficient. There are many | 396 values are deleted or copied, however these aren't sufficient. There are many |
406 implementations can expect that they will be informed of any relevant ``Value`` | 401 implementations can expect that they will be informed of any relevant ``Value`` |
407 before it appears in an alias query. However, popular clients such as ``GVN`` | 402 before it appears in an alias query. However, popular clients such as ``GVN`` |
408 don't support this, and are known to trigger errors when run with the | 403 don't support this, and are known to trigger errors when run with the |
409 ``AliasAnalysisDebugger``. | 404 ``AliasAnalysisDebugger``. |
410 | 405 |
411 Due to several of the above limitations, the most obvious use for the | |
412 ``AliasAnalysisCounter`` utility, collecting stats on all alias queries in a | |
413 compilation, doesn't work, even if the ``AliasAnalysis`` implementations don't | |
414 use ``FunctionPass``. There's no way to set a default, much less a default | |
415 sequence, and there's no way to preserve it. | |
416 | |
417 The ``AliasSetTracker`` class (which is used by ``LICM``) makes a | 406 The ``AliasSetTracker`` class (which is used by ``LICM``) makes a |
418 non-deterministic number of alias queries. This can cause stats collected by | 407 non-deterministic number of alias queries. This can cause debugging techniques |
419 ``AliasAnalysisCounter`` to have fluctuations among identical runs, for | 408 involving pausing execution after a predetermined number of queries to be |
420 example. Another consequence is that debugging techniques involving pausing | 409 unreliable. |
421 execution after a predetermined number of queries can be unreliable. | |
422 | 410 |
423 Many alias queries can be reformulated in terms of other alias queries. When | 411 Many alias queries can be reformulated in terms of other alias queries. When |
424 multiple ``AliasAnalysis`` queries are chained together, it would make sense to | 412 multiple ``AliasAnalysis`` queries are chained together, it would make sense to |
425 start those queries from the beginning of the chain, with care taken to avoid | 413 start those queries from the beginning of the chain, with care taken to avoid |
426 infinite looping, however currently an implementation which wants to do this can | 414 infinite looping, however currently an implementation which wants to do this can |
674 | 662 |
675 .. code-block:: bash | 663 .. code-block:: bash |
676 | 664 |
677 % opt -ds-aa -print-alias-sets -disable-output | 665 % opt -ds-aa -print-alias-sets -disable-output |
678 | 666 |
679 The ``-count-aa`` pass | |
680 ^^^^^^^^^^^^^^^^^^^^^^ | |
681 | |
682 The ``-count-aa`` pass is useful to see how many queries a particular pass is | |
683 making and what responses are returned by the alias analysis. As an example: | |
684 | |
685 .. code-block:: bash | |
686 | |
687 % opt -basicaa -count-aa -ds-aa -count-aa -licm | |
688 | |
689 will print out how many queries (and what responses are returned) by the | |
690 ``-licm`` pass (of the ``-ds-aa`` pass) and how many queries are made of the | |
691 ``-basicaa`` pass by the ``-ds-aa`` pass. This can be useful when debugging a | |
692 transformation or an alias analysis implementation. | |
693 | |
694 The ``-aa-eval`` pass | 667 The ``-aa-eval`` pass |
695 ^^^^^^^^^^^^^^^^^^^^^ | 668 ^^^^^^^^^^^^^^^^^^^^^ |
696 | 669 |
697 The ``-aa-eval`` pass simply iterates through all pairs of pointers in a | 670 The ``-aa-eval`` pass simply iterates through all pairs of pointers in a |
698 function and asks an alias analysis whether or not the pointers alias. This | 671 function and asks an alias analysis whether or not the pointers alias. This |