| 1 | //===---------------------------------------------------------------------===// |
| 2 | // Random Notes |
| 3 | //===---------------------------------------------------------------------===// |
| 4 | |
| 5 | //===---------------------------------------------------------------------===// |
| 6 | |
| 7 | To time GCC preprocessing speed without output, use: |
| 8 | "time gcc -MM file" |
| 9 | This is similar to -Eonly. |
| 10 | |
| 11 | //===---------------------------------------------------------------------===// |
| 12 | |
| 13 | C++ Template Instantiation benchmark: |
| 14 | http://users.rcn.com/abrahams/instantiation_speed/index.html |
| 15 | |
| 16 | //===---------------------------------------------------------------------===// |
| 17 | |
| 18 | TODO: File Manager Speedup: |
| 19 | |
| 20 | We currently do a lot of stat'ing for files that don't exist, particularly |
| 21 | when lots of -I paths exist (e.g. see the <iostream> example, check for |
| 22 | failures in stat in FileManager::getFile). It would be far better to make |
| 23 | the following changes: |
| 24 | 1. FileEntry contains a sys::Path instead of a std::string for Name. |
| 25 | 2. sys::Path contains timestamp and size, lazily computed. Eliminate from |
| 26 | FileEntry. |
| 27 | 3. File UIDs are created on request, not when files are opened. |
| 28 | These changes make it possible to efficiently have FileEntry objects for |
| 29 | files that exist on the file system, but have not been used yet. |
| 30 | |
| 31 | Once this is done: |
| 32 | 1. DirectoryEntry gets a boolean value "has read entries". When false, not |
| 33 | all entries in the directory are in the file mgr, when true, they are. |
| 34 | 2. Instead of stat'ing the file in FileManager::getFile, check to see if |
| 35 | the dir has been read. If so, fail immediately, if not, read the dir, |
| 36 | then retry. |
| 37 | 3. Reading the dir uses the getdirentries syscall, creating a FileEntry |
| 38 | for all files found. |
| 39 | |
| 40 | //===---------------------------------------------------------------------===// |
| 41 | // Specifying targets: -triple and -arch |
| 42 | //===---------------------------------------------------------------------===// |
| 43 | |
| 44 | The clang supports "-triple" and "-arch" options. At most one -triple and one |
| 45 | -arch option may be specified. Both are optional. |
| 46 | |
| 47 | The "selection of target" behavior is defined as follows: |
| 48 | |
| 49 | (1) If the user does not specify -triple, we default to the host triple. |
| 50 | (2) If the user specifies a -arch, that overrides the arch in the host or |
| 51 | specified triple. |
| 52 | |
| 53 | //===---------------------------------------------------------------------===// |
| 54 | |
| 55 | |
| 56 | verifyInputConstraint and verifyOutputConstraint should not return bool. |
| 57 | |
| 58 | Instead we should return something like: |
| 59 | |
| 60 | enum VerifyConstraintResult { |
| 61 | Valid, |
| 62 | |
| 63 | // Output only |
| 64 | OutputOperandConstraintLacksEqualsCharacter, |
| 65 | MatchingConstraintNotValidInOutputOperand, |
| 66 | |
| 67 | // Input only |
| 68 | InputOperandConstraintContainsEqualsCharacter, |
| 69 | MatchingConstraintReferencesInvalidOperandNumber, |
| 70 | |
| 71 | // Both |
| 72 | PercentConstraintUsedWithLastOperand |
| 73 | }; |
| 74 | |
| 75 | //===---------------------------------------------------------------------===// |
| 76 | |
| 77 | Blocks should not capture variables that are only used in dead code. |
| 78 | |
| 79 | The rule that we came up with is that blocks are required to capture |
| 80 | variables if they're referenced in evaluated code, even if that code |
| 81 | doesn't actually rely on the value of the captured variable. |
| 82 | |
| 83 | For example, this requires a capture: |
| 84 | (void) var; |
| 85 | But this does not: |
| 86 | if (false) puts(var); |
| 87 | |
| 88 | Summary of <rdar://problem/9851835>: if we implement this, we should |
| 89 | warn about non-POD variables that are referenced but not captured, but |
| 90 | only if the non-reachability is not due to macro or template |
| 91 | metaprogramming. |
| 92 | |
| 93 | //===---------------------------------------------------------------------===// |
| 94 | |
| 95 | We can still apply a modified version of the constructor/destructor |
| 96 | delegation optimization in cases of virtual inheritance where: |
| 97 | - there is no function-try-block, |
| 98 | - the constructor signature is not variadic, and |
| 99 | - the parameter variables can safely be copied and repassed |
| 100 | to the base constructor because either |
| 101 | - they have not had their addresses taken by the vbase initializers or |
| 102 | - they were passed indirectly. |
| 103 | |
| 104 | //===---------------------------------------------------------------------===// |
| 105 | |