|
150
|
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 //===---------------------------------------------------------------------===//
|
