brintos

brintos / llvm-project-archived public Read only

0
0
Text · 4.0 KiB · f06ea8c Raw
105 lines · plain
1//===---------------------------------------------------------------------===//2// Random Notes3//===---------------------------------------------------------------------===//4 5//===---------------------------------------------------------------------===//6 7To time GCC preprocessing speed without output, use:8   "time gcc -MM file"9This is similar to -Eonly.10 11//===---------------------------------------------------------------------===//12 13  C++ Template Instantiation benchmark:14     http://users.rcn.com/abrahams/instantiation_speed/index.html15 16//===---------------------------------------------------------------------===//17 18TODO: File Manager Speedup:19 20 We currently do a lot of stat'ing for files that don't exist, particularly21 when lots of -I paths exist (e.g. see the <iostream> example, check for22 failures in stat in FileManager::getFile).  It would be far better to make23 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 from26      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 for29 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, not33      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 if35      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 FileEntry38      for all files found.39 40//===---------------------------------------------------------------------===//41// Specifying targets:  -triple and -arch42//===---------------------------------------------------------------------===//43 44The clang supports "-triple" and "-arch" options. At most one -triple and one45-arch option may be specified.  Both are optional.46 47The "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 or51    specified triple.52 53//===---------------------------------------------------------------------===//54 55 56verifyInputConstraint and verifyOutputConstraint should not return bool.57 58Instead we should return something like:59 60enum VerifyConstraintResult {61  Valid,62 63  // Output only64  OutputOperandConstraintLacksEqualsCharacter,65  MatchingConstraintNotValidInOutputOperand,66 67  // Input only68  InputOperandConstraintContainsEqualsCharacter,69  MatchingConstraintReferencesInvalidOperandNumber,70 71  // Both72  PercentConstraintUsedWithLastOperand73};74 75//===---------------------------------------------------------------------===//76 77Blocks should not capture variables that are only used in dead code.78 79The rule that we came up with is that blocks are required to capture80variables if they're referenced in evaluated code, even if that code81doesn't actually rely on the value of the captured variable.82 83For example, this requires a capture:84  (void) var;85But this does not:86  if (false) puts(var);87 88Summary of <rdar://problem/9851835>: if we implement this, we should89warn about non-POD variables that are referenced but not captured, but90only if the non-reachability is not due to macro or template91metaprogramming.92 93//===---------------------------------------------------------------------===//94 95We can still apply a modified version of the constructor/destructor96delegation optimization in cases of virtual inheritance where:97  - there is no function-try-block,98  - the constructor signature is not variadic, and99  - the parameter variables can safely be copied and repassed100    to the base constructor because either101    - they have not had their addresses taken by the vbase initializers or102    - they were passed indirectly.103 104//===---------------------------------------------------------------------===//105