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