llvm.org GIT mirror llvm / cd11e45
* Use UTF-8 instead of soon-to-be-extinct ISO-8859-1 ;) * Use stylesheets instead of explicit <font> tags * Stop using <ul> for spacing layout * Close <a> and <p> tags git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9392 91177308-0d34-0410-b5e6-96231b3b80d8 Misha Brukman 15 years ago
1 changed file(s) with 300 addition(s) and 245 deletion(s). Raw diff Collapse all Expand all
0
1 Alias Analysis Infrastructure in LLVM
2
3
4
5
6
  Alias Analysis Infrastructure in LLVM
7 </tr>>
1 <html>
2
3
4
5 Alias Analysis Infrastructure in LLVM
6
7
8
9
10
11 Alias Analysis Infrastructure in LLVM
12
813
914
1015
  • Introduction
  • 4449

    4550
    4651
    47
    48
    49
    50
    51 Introduction
    52
    53
    54
    52
    53
    54 Introduction
    55
    56
    57
    58
    59

    5560 Alias Analysis (or Pointer Analysis) is a technique which attempts to determine
    5661 whether or not two pointers ever can point to the same object in memory.
    5762 Traditionally, Alias Analyses respond to a query with either a
    5863 href="#MustNoMay">Must, May, or No alias response, indicating that two
    5964 pointers do point to the same object, might point to the same object, or are
    60 known not to point to the same object.

    61
    65 known not to point to the same object.
    66

    67

    6268 The AliasAnalysis class is the
    6369 centerpiece of the LLVM Alias Analysis related infrastructure. This class is
    6470 the common interface between clients of alias analysis information and the
    6571 implementations providing it. In addition to simple alias analysis information,
    6672 this class exposes Mod/Ref information from those implementations which can
    6773 provide it, allowing for powerful analyses and transformations to work well
    68 together.

    69
    74 together.
    75

    76

    7077 This document contains information necessary to successfully implement this
    7178 interface, use it, and to test both sides. It also explains some of the finer
    7279 points about what exactly results mean. If you feel that something is unclear
    73 or should be added, please let me know.

    74
    75
    76
    77
    78
    79 AliasAnalysis Overview
    80
    81
    82
    80 or should be added, please let me
    81 know.
    82

    83
    84
    85
    86
    87 AliasAnalysis Overview
    88
    89
    90
    91
    92

    8393 The AliasAnalysis class defines
    8494 the interface that Alias Analysis implementations should support. This class
    8595 exports two important enums: AliasResult and ModRefResult
    8696 which represent the result of an alias query or a mod/ref query,
    87 respectively.

    88
    97 respectively.
    98

    99

    89100 The AliasAnalysis interface exposes information about memory, represented in
    90101 several different ways. In particular, memory objects are represented as a
    91102 starting address and size, and function calls are represented as the actual
    92103 call or invoke instructions that performs the call. The
    93104 AliasAnalysis interface also exposes some helper methods which allow you to get
    94 mod/ref information for arbitrary instructions.

    95
    96
    97
    98
      
    99
    100 Representation of Pointers
    101
    102
    105 mod/ref information for arbitrary instructions.
    106

    107
    108
    109
    110
    111 Representation of Pointers
    112
    113
    114
    115

    103116 Most importantly, the AliasAnalysis class provides several methods which are
    104117 used to query whether or not pointers alias, whether function calls can modify
    105 or read memory, etc.

    106
    118 or read memory, etc.
    119

    120

    107121 Representing memory objects as a starting address and a size is critically
    108122 important for precise Alias Analyses. For example, consider this (silly) C
    109 code:

    110
    123 code:
    124

    125

    111126
    
                      
                    
    112127 int i;
    113128 char C[2];
    118133 C[1] = A[9-i]; /* One byte store */
    119134 }
    120135
    121
    136

    137

    122138 In this case, the basicaa pass will disambiguate the stores to
    123139 C[0] and C[1] because they are accesses to two distinct
    124140 locations one byte apart, and the accesses are each one byte. In this case, the
    125141 LICM pass can use store motion to remove the stores from the loop. In
    126 constrast, the following code:

    127
    142 constrast, the following code:
    143

    144

    128145
    
                      
                    
    129146 int i;
    130147 char C[2];
    135152 C[1] = A[9-i]; /* One byte store */
    136153 }
    137154
    138
    155

    156

    139157 In this case, the two stores to C do alias each other, because the access to the
    140158 &C[0] element is a two byte access. If size information wasn't
    141159 available in the query, even the first case would have to conservatively assume
    142 that the accesses alias.

    143
    144
    145
    146
    147
      
    148
    149 Must, May, and No Alias Responses
    150
    151
    160 that the accesses alias.
    161

    162
    163
    164
    165
    166 Must, May, and No Alias Responses
    167
    168
    169
    170

    152171 An Alias Analysis implementation can return one of three responses: MustAlias,
    153172 MayAlias, and NoAlias. The No and May alias results are obvious: if the two
    154173 pointers may never equal each other, return NoAlias, if they might, return
    155 MayAlias.

    156
    174 MayAlias.
    175

    176

    157177 The Must Alias response is trickier though. In LLVM, the Must Alias response
    158178 may only be returned if the two memory objects are guaranteed to always start at
    159179 exactly the same location. If two memory objects overlap, but do not start at
    160 the same location, MayAlias must be returned.

    161
    162
    163
    164
    165
      
    166
    167 The getModRefInfo methods
    168
    169
    180 the same location, MayAlias must be returned.
    181

    182
    183
    184
    185
    186 The getModRefInfo methods
    187
    188
    189
    190

    170191 The getModRefInfo methods return information about whether the
    171192 execution of an instruction can read or modify a memory location. Mod/Ref
    172193 information is always conservative: if an action may read a location, Ref
    173 is returned.

    174
    175
    176
    177
    178
    179
    180 Writing a new AliasAnalysis Implementation
    181
    182
    183
    194 is returned.
    195

    196
    197
    198
    199
    200 Writing a new AliasAnalysis Implementation
    201
    202
    203
    204
    205

    184206 Writing a new alias analysis implementation for LLVM is quite straight-forward.
    185207 There are already several implementations that you can use for examples, and the
    186208 following information should help fill in any details. For a minimal example,
    187209 take a look at the no-aa
    188 implementation.

    189
    190
    191
    192
    193
      
    194
    195 Different Pass styles
    196
    197
    210 implementation.
    211

    212
    213
    214
    215
    216 Different Pass styles
    217
    218
    219
    220

    198221 The first step to determining what type of LLVM
    199222 pass you need to use for your Alias Analysis. As is the case with most
    200223 other analyses and transformations, the answer should be fairly obvious from
    201 what type of problem you are trying to solve:

    202
    224 what type of problem you are trying to solve:
    225

    226

    203227
    204
  • If you require interprocedural analysis, it should be a Pass.
  • 205
  • If you are a global analysis, subclass FunctionPass.
  • 206
  • If you are a local pass, subclass BasicBlockPass.
  • 207
  • If you don't need to look at the program at all, subclass
  • 208 ImmutablePass.
    209

    210
    228
  • If you require interprocedural analysis, it should be a
  • 229 Pass.
    230
  • If you are a global analysis, subclass FunctionPass.
  • 231
  • If you are a local pass, subclass BasicBlockPass.
  • 232
  • If you don't need to look at the program at all, subclass
  • 233 ImmutablePass.
    234
    235

    236

    211237 In addition to the pass that you subclass, you should also inherit from the
    212238 AliasAnalysis interface, of course, and use the
    213239 RegisterAnalysisGroup template to register as an implementation of
    214 AliasAnalysis.

    215
    216
    217
    218
    219
      
    220
    221 Required initialization calls
    222
    223
    240 AliasAnalysis.
    241

    242
    243
    244
    245
    246 Required initialization calls
    247
    248
    249
    250

    224251 Your subclass of AliasAnalysis is required to invoke two methods on the
    225252 AliasAnalysis base class: getAnalysisUsage and
    226253 InitializeAliasAnalysis. In particular, your implementation of
    227254 getAnalysisUsage should explicitly call into the
    228255 AliasAnalysis::getAnalysisUsage method in addition to doing any
    229256 declaring any pass dependencies your pass has. Thus you should have something
    230 like this:

    231
    257 like this:
    258

    259

    232260
    
                      
                    
    233261 void getAnalysisUsage(AnalysisUsage &AU) const {
    234262 AliasAnalysis::getAnalysisUsage(AU);
    235263 // declare your dependencies here.
    236264 }
    237265
    238
    266

    267

    239268 Additionally, your must invoke the InitializeAliasAnalysis method from
    240269 your analysis run method (run for a Pass,
    241270 runOnFunction for a FunctionPass, runOnBasicBlock for
    242271 a BasicBlockPass, or InitializeAliasAnalysis for an
    243 ImmutablePass). For example (as part of a Pass):

    244
    272 ImmutablePass). For example (as part of a Pass):
    273

    274

    245275
    
                      
                    
    246276 bool run(Module &M) {
    247277 InitializeAliasAnalysis(this);
    249279 return false;
    250280 }
    251281
    252
    253
    254
    255
    256
      
    257
    258 Interfaces which may be specified
    259
    260
    282

    283
    284
    285
    286
    287 Interfaces which may be specified
    288
    289
    290
    291

    261292 All of the AliasAnalysis virtual
    262293 methods default to providing conservatively correct information (returning "May"
    263294 Alias and "Mod/Ref" for alias and mod/ref queries respectively). Depending on
    264295 the capabilities of the analysis you are implementing, you just override the
    265296 interfaces you can improve.
    266
    267
    268
    269
    270
      
    271
    272 The AliasAnalysis chaining behavior
    273
    274
    297

    298
    299
    300
    301
    302 The AliasAnalysis chaining behavior
    303
    304
    305
    306

    275307 With only two special exceptions (the basicaa and
    276308 href="#no-aa">no-aa passes) every alias analysis pass should chain
    277309 to another alias analysis implementation (for example, you could specify
    278310 "-basic-aa -ds-aa -andersens-aa -licm" to get the maximum benefit from
    279311 the three alias analyses). To do this, simply "Require" AliasAnalysis in your
    280312 getAnalysisUsage method, and if you need to return a conservative
    281 MayAlias or Mod/Ref result, simply chain to a lower analysis.

    282
    283
    284
    285
    286
      
    287
    288 Efficiency Issues
    289
    290
    313 MayAlias or Mod/Ref result, simply chain to a lower analysis.
    314

    315
    316
    317
    318
    319 Efficiency Issues
    320
    321
    322
    323

    291324 From the LLVM perspective, the only thing you need to do to provide an efficient
    292325 alias analysis is to make sure that alias analysis queries are serviced
    293326 quickly. The actual calculation of the alias analysis results (the "run"
    294327 method) is only performed once, but many (perhaps duplicate) queries may be
    295328 performed. Because of this, try to move as much computation to the run method
    296 as possible (within reason).

    297
    298
    299
    300
    301
    302 Using AliasAnalysis results
    303
    304
    305
    329 as possible (within reason).
    330

    331
    332
    333
    334
    335 Using AliasAnalysis results
    336
    337
    338
    339
    340

    306341 There are several different ways to use alias analysis results. In order of
    307 preference, these are...

    308
    309
    310
    311
      
    312
    313 Using the -load-vn Pass
    314
    315
    342 preference, these are...
    343

    344
    345
    346
    347
    348 Using the -load-vn Pass
    349
    350
    351
    352

    316353 The load-vn pass uses alias analysis to provide value numbering
    317354 information for load instructions. If your analysis or transformation
    318355 can be modelled in a form that uses value numbering information, you don't have
    319356 to do anything special to handle load instructions: just use the
    320 load-vn pass, which uses alias analysis.

    321
    322
    323
    324
    325
      
    326
    327 Using the AliasSetTracker class
    328
    329
    357 load-vn pass, which uses alias analysis.
    358

    359
    360
    361
    362
    363 Using the AliasSetTracker class
    364
    365
    366
    367

    330368 Many transformations need information about alias sets that are active in
    331369 some scope, rather than information about pairwise aliasing. The
    332370 href="/doxygen/classAliasSetTracker.html">AliasSetTracker class is used
    333371 to efficiently build these Alias Sets from the pairwise alias analysis
    334 information provided by the AliasAnalysis interface.

    335
    372 information provided by the AliasAnalysis interface.
    373

    374

    336375 First you initialize the AliasSetTracker by use the "add" methods to
    337376 add information about various potentially aliasing instructions in the scope you
    338377 are interested in. Once all of the alias sets are completed, your pass should
    339378 simply iterate through the constructed alias sets, using the AliasSetTracker
    340 begin()/end() methods.

    341
    379 begin()/end() methods.
    380

    381

    342382 The AliasSets formed by the AliasSetTracker are guaranteed to
    343383 be disjoint, calculate mod/ref information for the set, and keep track of
    344384 whether or not all of the pointers in the set are Must aliases. The
    345385 AliasSetTracker also makes sure that sets are properly folded due to call
    346 instructions, and can provide a list of pointers in each set.

    347
    386 instructions, and can provide a list of pointers in each set.
    387

    388

    348389 As an example user of this, the Loop
    349390 Invariant Code Motion pass uses AliasSetTrackers to build alias information
    350391 about each loop nest. If an AliasSet in a loop is not modified, then all load
    351392 instructions from that set may be hoisted out of the loop. If any alias sets
    352393 are stored and are must alias sets, then the stores may be sunk to
    353394 outside of the loop. Both of these transformations obviously only apply if the
    354 pointer argument is loop-invariant.

    355
    356
    357
    358
    359
      
    360
    361 Using the AliasAnalysis interface directly
    362
    363
    395 pointer argument is loop-invariant.
    396

    397
    398
    399
    400
    401 Using the AliasAnalysis interface directly
    402
    403
    404
    405

    364406 As a last resort, your pass could use the AliasAnalysis interface directly to
    365407 service your pass. If you find the need to do this, please
    366408 href="mailto:sabre@nondot.org">let me know so I can see if something new
    367 needs to be added to LLVM.

    368
    369
    370
    371
    372
    373 Helpful alias analysis related tools
    374
    375
    376
    409 needs to be added to LLVM.
    410

    411
    412
    413
    414
    415 Helpful alias-analysis-related tools
    416
    417
    418
    419
    420

    377421 If you're going to be working with the AliasAnalysis infrastructure, there are
    378 several nice tools that may be useful for you and are worth knowing about...

    379
    380
    381
    382
      
    383
    384 The -no-aa pass
    385
    386
    422 several nice tools that may be useful for you and are worth knowing about...
    423

    424
    425
    426
    427
    428 The -no-aa pass
    429
    430
    431
    432

    387433 The -no-aa analysis is just like what it sounds: an alias analysis that
    388434 never returns any useful information. This pass can be useful if you think that
    389435 alias analysis is doing something wrong and are trying to narrow down a problem.
    390436 If you don't specify an alias analysis, the default will be to use the
    391 basicaa pass which does quite a bit of disambiguation on its own.

    392
    393
    394
    395
    396
      
    397
    398 The -print-alias-sets pass
    399
    400
    437 basicaa pass which does quite a bit of disambiguation on its own.
    438

    439
    440
    441
    442
    443
    444 The -print-alias-sets pass
    445
    446
    447
    448

    401449 The -print-alias-sets pass is exposed as part of the analyze
    402450 tool to print out the Alias Sets formed by the
    403451 href="#ast">AliasSetTracker class. This is useful if you're using
    404 the AliasSetTracker.

    405
    406
    407
    408
    409
      
    410
    411 The -count-aa pass
    412
    413
    452 the AliasSetTracker.
    453

    454
    455
    456
    457
    458 The -count-aa pass
    459
    460
    461
    462

    414463 The -count-aa pass is useful to see how many queries a particular pass
    415464 is making and what kinds of responses are returned by the alias analysis. An
    416 example usage is:

    417
    465 example usage is:
    466

    467

    418468
    
                      
                    
    419469 $ opt -basicaa -count-aa -ds-aa -count-aa -licm
    420470
    421
    471

    472

    422473 Which will print out how many queries (and what responses are returned) by the
    423474 -licm pass (of the -ds-aa pass) and how many queries are made
    424475 of the -basicaa pass by the -ds-aa pass. This can be useful
    425 when evaluating an alias analysis for precision.

    426
    427
    428
    429
      
    430
    431 The -aa-eval pass
    432
    433
    476 when evaluating an alias analysis for precision.
    477

    478
    479
    480
    481
    482 The -aa-eval pass
    483
    484
    485
    486

    434487 The -aa-eval pass simply iterates through all pairs of pointers in a
    435488 function and asks an alias analysis whether or not the pointers alias. This
    436489 gives an indication of the precision of the alias analysis. Statistics are
    437 printed.

    438
    439
    440
    441
    490 printed.
    491

    492
    493
    442494
    443495
    444496
    447499
    448500 Last modified: Tue Mar 4 13:36:53 CST 2003
    449501
    450
    502
    503
    504
    505