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