This option can be useful for end users who want to know why they
ended up with a ton of different variants of the "std" module in their
module cache. This problem should go away over time, as we reduce the
need for module variants, but it will never go away entirely.
llvm-svn: 178148
As far as simplify_type is concerned, there are 3 kinds of smart pointers:
* const correct: A 'const MyPtr<int> &' produces a 'const int*'. A
'MyPtr<int> &' produces a 'int *'.
* always const: Even a 'MyPtr<int> &' produces a 'const int*'.
* no const: Even a 'const MyPtr<int> &' produces a 'int*'.
This patch then does the following:
* Removes the unused specializations. Since they are unused, it is hard
to know which kind should be implemented.
* Make sure we don't drop const.
* Fix the default forwarding so that const correct pointer only need
one specialization.
* Simplifies the existing specializations.
llvm-svn: 178147
This is a follow-up to r178073 (which should actually make target-customized
spilling work again).
I still don't have a regression test for this (but it would be good to have
one; Thumb 1 and Mips16 use this callback as well).
Patch by Richard Sandiford.
llvm-svn: 178137
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 178127
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 178126
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 178125
The register parameter in these instructions becomes the base register in an
r+i ld instruction (and, thus, cannot be r0).
This is not yet testable because we don't yet allocate r0 (and even then any
test would be very fragile).
llvm-svn: 178121
Either operand of these pseudo instructions can be transformed into the first
operand of an isel instruction (and this operand cannot be r0).
This is not yet testable because we don't yet allocate r0 (and even when we do,
any test would be very fragile).
llvm-svn: 178119
Like the addi/addis instructions themselves, these pseudo instructions also
cannot have r0 as their register parameter (because it will be interpreted as
the value 0).
This is not yet testable because we don't yet allocate r0 (and even when we do,
any regression test would be very fragile because it would depend on the
register allocator heuristics).
llvm-svn: 178118
Module "sse" implicitly exports module "sse2".
This is bad because we also have module "sse2" export module "sse" (as intended) so we end up with a cycle
in the module import graph:
1. sse2 -> (also imports) sse
2. sse -> (also imports) sse2
To eliminate the cycle remove 2.; importing module "sse2" will also import module "sse", but just importing
module "sse" will not also import module "sse2".
rdar://13240552
llvm-svn: 178117
Some implementation detail in the forgotten past required the link
register to be placed in the GPRC and G8RC register classes. This is
just wrong on the face of it, and causes several extra intersection
register classes to be generated. I found this was having evil
effects on instruction scheduling, by causing the wrong register class
to be consulted for register pressure decisions.
No code generation changes are expected, other than some minor changes
in instruction order. Seven tests in the test bucket required minor
tweaks to adjust to the new normal.
llvm-svn: 178114
the system macro uses a not identical definition compared to a macro from the clang headers.
For example (these come from different modules):
\#define LONG_MAX __LONG_MAX__ (clang's limits.h)
\#define LONG_MAX 0x7fffffffffffffffL (system's limits.h)
in which case don't mark them ambiguous to avoid the "ambiguous macro expansion" warning.
llvm-svn: 178109
Also update "test/Modules/macros.c" to test modified semantics:
-When there is an ambiguous macro, expand using the latest introduced version, not the first one.
-#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause
undefining of macros in the translation unit that imported that submodule.
This reduces macro namespace interference across modules.
llvm-svn: 178105
uninstantiated exception specification when a special member within a class
template is both defaulted and given an exception specification on its first
declaration.
llvm-svn: 178103
The test was removed since I had not turned off the test during release
builds. This fails since ARC annotations support is conditionally
compiled out during release builds. I added the proper requires header
to assuage this issue.
llvm-svn: 178101
This is just the basic groundwork for supporting DW_TAG_imported_module but I
wanted to commit this before pushing support further into Clang or LLVM so that
this rather churny change is isolated from the rest of the work. The major
churn here is obviously adding another field (within the common DIScope prefix)
to all DIScopes (files, classes, namespaces, lexical scopes, etc). This should
be the last big churny change needed for DW_TAG_imported_module/using directive
support/PR14606.
llvm-svn: 178099
Douglas Gregor