For the Objective-C case, we do not have a "function type" notion, so we actually end up wrapping the clang ObjCMethodDecl in the Impl object, and ask function-y questions of it
In general, you can always ask for return type, number of arguments, and type of each argument using the TypeMemberFunction layer - but in the C++ case, you can also acquire a Type object for the function itself, which instead you can't do in the Objective-C case
llvm-svn: 218132
To reduce the size of -gmlt data, skip the subprograms without any
inlined subroutines. Since we've now got the ability to make these
determinations in the backend (funnily enough - we added the flag so we
wouldn't produce ranges under -gmlt, but with this change we use the
flag, but go back to producing ranges under -gmlt).
Instead, just produce CU ranges to inform the consumer which parts of
the code are described by this CU's line table. Tools could inspect the
line table directly to compute the range, but the CU ranges only seem to
be about 0.5% of object/executable size, so I'm not too worried about
teaching llvm-symbolizer that trick just yet - it's certainly a possible
piece of future work.
Update an llvm-symbolizer test just to demonstrate that this schema is
acceptable there (if it wasn't, the compiler-rt tests would catch this,
but good to have an in-llvm-tree test for llvm-symbolizer's behavior
here)
Building the clang binary with -gmlt with this patch reduces the total
size of object files by 5.1% (5.56% without ranges) without compression
and the executable by 4.37% (4.75% without ranges).
llvm-svn: 218129
Summary:
Make DynTypedNode have the dynamic type of the object, instead of its static type.
Some optimizations that are in the works require that the nodes have the right type.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5411
llvm-svn: 218127
Summary:
This will allow to request the creation of a forward delacred variable
at is point of use (for imported declarations, this will be
DwarfDebug::constructImportedEntityDIE) rather than having to put the
forward decl in a retention list.
Note that getOrCreateGlobalVariable returns the actual definition DIE when the
routine creates a declaration and a definition DIE. If you agree this is the
right behavior, then I'll have a followup patch that registers the definition
in the DIE map instead of the declaration as it is today (this 'breaks' only
one test, where we test that the imported entity is the declaration). I'm
not sure what's best here, but it's easy enough for a consumer to follow the
DW_AT_specification link to get to the declaration, whereas it takes more
work to find the actual definition from a declaration DIE.
Reviewers: echristo, dblaikie, aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5381
llvm-svn: 218126
Summary:
getFileNameForUnit() is basically a wrapper around LineTable::getFileNameByIndex().
Fold its additional functionality (adding the DWARFUnit compilation dir) into
LineTable::getFileNameByIndex().
getFileLineInfoForCompileUnit() is a wrapper around getFileNameForUnit(). As
a function to search the line information by address, it seems natural to put
it in the LineTable also.
Before this commit only the Context with its private helpers could do Linetable
lookups. This newly exposed feature will be used by the DIE dumping code to
get access to file information referenced in DIE attributes.
This commit has already been partly reviewed in D5192 and contained an
additional and a bit controversial 'realpath' call that is left out of this
patch. We can reinstate that realpath code later if it is desirable.
Test Plan:
The patch contains no tests as it should be functionally equivalent to the
previous code. As requested in the last review, I checked if the relative
path handling copied from the Context to LineTable::getFileNameByIndex()
was covered, and indeed the symbolizer tests fail if it is removed.
Reviewers: dblaikie, echristo, aprantl, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5354
llvm-svn: 218125
* Allow user SEGV handler if Android-L-like setup is detected.
Necessary for correctness.
* Change file context labels on the wrapper script to appease SELinux.
llvm-svn: 218124
The heuristic used by DAGCombine to form FMAs checks that the FMUL has only one
use, but this is overly-conservative on some systems. Specifically, if the FMA
and the FADD have the same latency (and the FMA does not compete for resources
with the FMUL any more than the FADD does), there is no need for the
restriction, and furthermore, forming the FMA leaving the FMUL can still allow
for higher overall throughput and decreased critical-path length.
Here we add a new TLI callback, enableAggressiveFMAFusion, false by default, to
elide the hasOneUse check. This is enabled for PowerPC by default, as most
PowerPC systems will benefit.
Patch by Olivier Sallenave, thanks!
llvm-svn: 218120
They are added to adxintrin.h but outside __ADX__ block.
These intrinics generates adc and sbb correspondingly that were available before ADX
llvm-svn: 218118
to undef lanes as well as defined widenable lanes. This dramatically
improves the lowering we use for undef-shuffles in a zext-ish pattern
for SSE2.
llvm-svn: 218115
Not sure why I only did SSSE3 here. Also, I've left out some of the SSE2
ones because the shuffles are so absurd it's not worth transcribing
them. Will try to fix them to be sane and then check them.
llvm-svn: 218114
This fixes two problems which are usualy caused together:
1) The elements of an isl AST access expression could be pointers
not only integers, floats and vectores thereof.
2) The runtime alias checks need to compare pointers but if they
are of a different type we need to cast them into a "max" type
similar to the non pointer case.
llvm-svn: 218113
shuffles that are zext-ing.
Not a lot to see here; the undef lane variant is better handled with
pshufd, but this improves the actual zext pattern.
llvm-svn: 218112
This patch only considers the difference between the length of the
shortest and longest element, but we might want to look at other
features (token count, etc.) in future.
Before:
std::vector<MyValues> aaaaaaaaaaaaaaaaaaa{
aaaaaaa, aaaaaaaaaa,
aaaaa, aaaaaaaaaaaaaaa,
aaa, aaaaaaaaaa,
a, aaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaa,
aaaaaaa, a};
After:
std::vector<MyValues> aaaaaaaaaaaaaaaaaaa{
aaaaaaa, aaaaaaaaaa, aaaaa, aaaaaaaaaaaaaaa, aaa, aaaaaaaaaa, a,
aaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaa, aaaaaaa, a};
llvm-svn: 218111
The filename-equivalence flag allows you to show coverage when your
source files don't have the same full paths as those that generated
the data. This is mostly useful for writing tests in a cross-platform
way.
This wasn't triggering in cases where the filename was derived
directly from the coverage data, which meant certain types of test
case were impossible to write. This patch fixes that, and following
patches involve tests that need this.
llvm-svn: 218108
Cache the machine type value of the linking context. We need this in order to
calculate the virtual address of the atom when resolving function symbols.
Windows on ARM must check if the atom is a function and if so, set the Thumb bit
for the returned virtual address. Failure to do so will result in an abnormal
exit due to a trap caused by invalid instruction decoding. The same information
can be used to determine the relocation type that was previously being done via
is64 to select between x86 and x86_64.
llvm-svn: 218106
Accept /machine:arm as an argument. This is changed to support ARM NT.
Although there is no way to differentiate between ARM (Windows CE) and ARM NT
(Windows on ARM), since LLVM currently only supports Windows on ARM, simply take
/machine:arm to mean Windows on ARM.
llvm-svn: 218105
Rather than saving whether we are targeting 64-bit x86 (x86_64), simply convert
the single use of that information to the actual relocation type. This will
permit the selection of non-x86 relocation types (e.g. for WoA support).
Inline the access of the machine type field as it is relatively cheap (a couple
of pointer dereferences) rather than storing the relocation type as a member
variable.
llvm-svn: 218104
When we encounter an unknown machine type, we print out the machine type magic.
However, we would print out the magic in decimal rather than hex. Perform this
conversion to make it easier to identify what machine is unsupported.
llvm-svn: 218103
to the new vector shuffle lowering code.
This allows us to emit PMOVZX variants consistently for patterns where
it is a viable lowering. This instruction is both fast and allows us to
fold loads into it. This only hooks the new lowering up for i16 and i8
element widths, mostly so I could manage the change to the tests. I'll
add the i32 one next, although it is significantly less interesting.
One thing to note is that we already had some tests for these patterns
but those tests had far less horrible instructions. The problem is that
those tests weren't checking the strict start and end of the instruction
sequence. =[ As a consequence something changed in the lowering making
us generate *TERRIBLE* code for these patterns in SSE2 through SSSE3.
I've consolidated all of the tests and spelled out the madness that we
currently emit for these shuffles. I'm going to try to figure out what
has gone wrong here.
llvm-svn: 218102
With this optimization, we will not always insert zext for values crossing
basic blocks, but insert sext if the users of a value crossing basic block
has preference of sign predicate.
llvm-svn: 218101
This omission will be done in a fancier manner once we're dealing with
"put gmlt in the skeleton CUs under fission" - it'll have to be
conditional on the kind of CU we're emitting into (skeleton or gmlt).
llvm-svn: 218098
The field is defined as:
If the third field is present, non-null, and points to a global variable or function, the initializer function will only run if the associated data from the current module is not discarded.
And without COMDATs we can't implement that.
llvm-svn: 218097
__ARM_ARCH is part of the ACLE specification. At least clang and GCC have
supported this part of the ACLE for some time now. Let the compiler provide the
proper definition for the macro rather than try to guess it.
llvm-svn: 218095
Clang can already handle
-------------------------------------------
struct S {
static const int x;
};
template<typename T> struct U {
static const int k;
};
template<typename T> const int U<T>::k = T::x;
const int S::x = 42;
extern const int *f();
const int *g() { return &U<S>::k; }
int main() {
return *f() + U<S>::k;
}
const int *f() { return &U<S>::k; }
-------------------------------------------
since r217264 which puts the .inint_array section in the same COMDAT
as the variable.
This patch allows the linker to more easily delete some dead code and data by
putting the guard variable and init function in the same COMDAT.
llvm-svn: 218089
warns when a guarded variable is passed by reference as a function argument.
This is released as a separate warning flag, because it could potentially
break existing code that uses thread safety analysis.
llvm-svn: 218087
CodeGen would try to come up with an LLVM IR type for a pointer to
member type on the way to forming an LLVM IR type for a pointer to
pointer to member type.
However, if the pointer to member representation has not been locked in yet,
we would not be able to come up with a pointer to member IR type.
In these cases, make the pointer to member type an incomplete type.
This will make the pointer to pointer to member type a pointer to an
incomplete type. If the class eventually obtains an inheritance model,
we will make the pointer to member type represent the actual inheritance
model.
Differential Revision: http://reviews.llvm.org/D5373
llvm-svn: 218084
This patch fixes a forbidden use of Twine. It should only be used
as an intermediary value, but never stored.
This caused a bug in lld when running on Linux and compiled with
optimizations - it couldn't properly search libs.
Patch from Rafael Auler!
llvm-svn: 218083
Todd Fiala