Large is CodeModel::Model::Large, not CodeModel::Model::Medium. Thanks to
majnemer for pointing out the typo! Its unclear how to test the mapped value in
the compiler, the tests already cover the driver side.
llvm-svn: 208335
Summary:
When using #line directives, FileManager::getFile() will return a nil
entry. This triggers an assert in translateFileLineCol().
This patch handles nil FileEntry instances by emitting a note that the
location could not be translated back to a SourceLocation. I don't
really like this solution, but we are translating presumed locations,
so some information has already been lost.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3625
llvm-svn: 208315
This addresses an existing FIXME item in the driver. The code model flag was
parsed in the actual tool rather than in the driver. This was problematic since
the value may be invalid. In that case, we would silently treat it as a default
value in non-assert builds, and abort in assert builds. Add a check in the
driver to validate that the value being passed is valid, and if not provide a
proper error message.
llvm-svn: 208275
Previously we calculated the shift amount based upon DataLayout::getTypeAllocSizeInBits.
This will only work for legal types - types such as i24 that are created as part of
structs for bitfields will return "32" from that function. Change to using
getTypeSizeInBits.
It turns out that AArch64 didn't run across this problem because it always returned
[1 x i64] as the type for a bitfield, whereas ARM64 returns i64 so goes down this
(better, but wrong) codepath.
llvm-svn: 208231
While constructing ObjC Interface types we might create the declaration
of some normal C++ types, thus adding things to the ReplaceMap. Make
sure we process the ReplaceMap after the ObjC interfaces.
In theory we know at this point, since we're at the end of the TU, that
we won't be upgrading any declarations to definitions, so we could just
construct non-temporary nodes, but that would require extra state in
CGDebugInfo to conditionalize the creation of declaration nodes which
seems annoying/more work than is appropriate.
llvm-svn: 208226
In cases where a struct must, according to the AAPCS, not be split between
general purpose and floating point registers, we use
ABIArgInfo::getExpandWithPadding to add the padding arguments. However,
ExpandWithPadding does not work if the struct contains bitfields, so we
instead must use ABIArgInfo::getDirect.
llvm-svn: 208185
This makes it easier to see where a global ctor comes from, and it also makes
ASan's init order analyzer output easier to understand. gcc does this too,
but only in -fPIC mode for some reason. Don't do this for constructors with
explicit init priority.
Also prepend "sub_" before the 'I', that way regular constructors stay
lexicographically after symbols with init priority (because
ord('s') > ord('I')). gold seems to ignore the name of constructor symbols,
and ld only looks at the symbol if it includes an init priority, which this
patch doesn't change.
Before: __GLOBAL_I_a
Now: __GLOBAL_sub_I_myfile.cc
llvm-svn: 208128
Reverting r208106 to reapply r208065 with a fix for the regression. The
issue was that the enum tried to be built even if the declaration hadn't
been constructed for debug info - presenting problems for enum templates
and typedefs of enums with names for linkage purposes.
Original commit message:
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
llvm-svn: 208114
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
llvm-svn: 208065
CGDebugInfo and DIBuilder were lax in their handling of temporary
MDNodes. All temporary nodes need to be deleted, which means they need
to be RAUW'd with a permanent node. This was not happening.
To ensure this, leverage DIBuilder's new ability to create both
permanent and temporary declarations. Ensure all temporary declarations
are RAUW'd, even with itself. (DIDescriptor::RAUW handles the case where
it is replaced with itself and creates a new, duplicate permanent node
to replace itself with)
This means that all temporary declarations must be added to the
ReplacementMap even if they're never upgraded to definitions - so move
the point of insertion into the map to the point of creation of the
declarations.
llvm-svn: 208055
This takes a different approach than the
completedType/requiresCompleteType work which relies on AST callbacks to
upgrade the type declaration to a definition. Instead, just defer
constructing the definition to the end of the translation unit.
This works because the definition is never needed by other debug info
(so far as I know), whereas the definition of a struct may be needed by
other debug info before the end of the translation unit (such as
emitting the definition of a member function which must refer to that
member function's declaration).
If we had a callback for whenever an IVar was added to an ObjC interface
we could use that, and remove the need for the ObjCInterfaceCache, which
might be nice. (also would need a callback for when it was more than
just a declaration so we could get properties, etc).
A side benefit is that we also don't need the CompletedTypeCache
anymore. Just rely on the declaration-ness of a type to decide whether
its definition is yet to be emitted.
There's still the PR19562 memory leak, but this should hopefully make
that a bit easier to approach.
llvm-svn: 208015
Items were being redundantly added to the replacement map (both when the
declaration was created, and then again when its definition was
constructed) which caused extra handling to be required when walking the
map (as elements may've already been replaced due to prior entries). By
avoiding adding the duplicates, the checks in the replacement handling
can be replaced with assertions.
llvm-svn: 208000
Currently, users get error messages about RTTI descriptor mangling with
no useful source location. This addresses that.
Another approach would be to disable C++ exceptions by default in the
driver when using the Microsoft C++ ABI. However, this makes it
impossible to parse system headers that use exception handling
constructs. By delaying the error to IRgen, we can figure out if we
actually need to emit code for this construct. Additionally, users who
are only interested in building refactoring tools on Windows still get a
correct AST without having to add flags. Finally, this is consistent
with what we do for SEH.
llvm-svn: 207999
We would sometimes incorrectly give a thread-wrapper external linkage
instead of internal linkage if we had only CodeGen'd it's declaration,
not it's definition.
This fixes PR19655.
llvm-svn: 207988
Add support for the remaining hints from the ACLE. Although __dbg is listed as
a hint, it is handled different, so it is not covered by this change.
llvm-svn: 207930
initializing an array unless we need it. Specifically, position the
creation of a new basic block after we've checked all of the cases that
bypass the need for it.
Fixes another leak in test/CodeGen* found by LSan.
llvm-svn: 207900
Passing objects directly (in registers or memory) creates a second copy
of the object in the callee. The callee always destroys its copy, but
we also have to destroy any temporary created in the caller. In other
words, copy elision of these kinds of objects is impossible.
Objects larger than 8 bytes with non-trivial dtors and trivial copy
ctors are still passed indirectly, and we can still elide copies of
them.
Fixes PR19640.
llvm-svn: 207889
condition to a constant and emit only the relevant statement. In that
case, we were previously creating the epilog jump destination, a cleanup
scope, and emitting any condition variable into it. Instead, we can emit
the condition variable (if we have one) into the cleanup scope used for
the entire folded case sequence. We avoid creating a jump dest, a basic
block, and an extra cleanup scope. Win!
llvm-svn: 207888
dependent-type-member-pointer.cpp is failing on a win64 bot because
-fms-extensions is not enabled. Use ConvertType rather than relying on
the inheritance attributes. It's less code, but probably slower.
llvm-svn: 207819
The Win64 ABI docs on MSDN say that arguments bigger than 8 bytes are
passed by reference. Prior to this change, we were only applying this
logic to RecordType arguments. This affects both the Itanium and
Microsoft C++ ABIs.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D3587
llvm-svn: 207817
This code is trying to test if the pointer is *not* null. Therefore we
should use 'or' instead of 'and' to combine the results of 'icmp ne'.
This logic is consistent with the general member pointer comparison code
in EmitMemberPointerComparison.
llvm-svn: 207815
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
llvm-svn: 207776
We were destroying them in the callee, and then again in the caller. We
should use an EH-only cleanup and disable it at the point of the call
for win64, even though we don't use inalloca.
llvm-svn: 207733
After this patch clang will ignore -fdwarf2-cfi-asm and -ffno-dwarf2-cfi-asm and
always print assembly that uses cfi directives.
In llvm, MC itself supports cfi since the end of 2010 (support started
in r119972, is reported in the 2.9 release notes).
In binutils the support has been around for much longer. It looks like
support started to be added in May 2003. It is available in 2.15
(31-Aug-2011, 2.14 is from 12-Jun-2003).
llvm-svn: 207602
and no return expr at the end of the function.
The "function has only simple returns" check in FinishFunction tests
whether the number of simple return exprs equals the number of return
exprs, but so far a fallthrough at the end of a function was not counted
as a return, which would result in cleanup code being associated with the
wrong source line.
rdar://problem/16733984.
llvm-svn: 207480
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
llvm-svn: 207451
Prior to this patch, CGRecordLower assumed that virtual bases could not
be placed before the nvsize of an object. This isn't true in Itanium
mode, virtual bases are placed at dsize rather than vnsize and in the
case of zero sized non-virtual bases nvsize can be larger than dsize.
This patch fixes CGRecordLowering to avoid an assert and to clip
bitfields properly in this case. A test case is included.
llvm-svn: 207280
The __yield intrinsic generates a hint instruction to indicate that the thread
is not performing any useful operations at the moment. This is for
compatibility with MSVC, although, the intrinsic is also part of the ACLE, and
is enabled globally as a result.
llvm-svn: 207275
Almost all linkage calculation for VarDecls occured inside of
GetLLVMLinkageVarDefinition except for static data members. Centralize
the logic so that it can be more readily reused.
No functionality change.
llvm-svn: 207241
It turns out that linkage and visibility have rather similar logic for
both functions and non-variable globals. Split the calculation out so
that both sides may share this code.
No functionality change.
llvm-svn: 207239
We don't assign counters for implicit Decls, but we were emitting code
to increment the (non-existent) counters and adding empty counter
lists in the output. This fixes the checks in assignRegionCounters and
emitInstrumentationData to do the right thing, and adds an assert for
the pathological case of emitting zero counters.
llvm-svn: 207203
We were using the same guard variable and failing to initialize the
second global.
Clang is still not MS ABI compatible in this area. Fixing that is
PR16959, which will require LLVM changes to @llvm.global_ctors.
llvm-svn: 207008
We previously treated ARM separately from the generic Itanium ABI for
initializing guard variables. This code duplication led to things like
the ARM path missing the memory barrier for threadsafe handling, and a
highly misleading comment about how we were (mis)using the generic ABI
for ARM64 when really it went through the ARM codepath.
This unifies the two code paths. Functionally, this changes the ARM
and ARM64 codepath to use one byte loads instead of 4 and 8,
respectively, and adds the missing atomic acquire to these loads.
Other architectures are unchanged.
llvm-svn: 206937
Summary:
This allows callers of Diags.Report() to append a value to the name of
the flag associated with the diagnostic. This is useful in cases like
the -Rpass flag, where we want the diagnostic to show the name of the
pass that matched the pattern. Instead of showing "... [-Rpass]", this
allows us to show "... [-Rpass=passname]".
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D3441
llvm-svn: 206826
parts of Clang. I don't really have any opinion about whether using that
macro is good or bad, but its odd that this is the only one, and Eric
seemed happy with just nuking it for now.
llvm-svn: 206806
Unlike the standard AAPCS64 ABI, variadic arguments are always passed on the
stack with the Darwin ABI, and this was not being considered when deciding
whether to expand HFA/HVA arguments in a call. An HFA argument with a "float"
base type was being expanded into separate "float" arguments, each of which
was then extended to a double, resulting in a serious mismatch from what is
expected by the va_arg implementation. <rdar://problem/15777067>
llvm-svn: 206729
Update clang to use the InstrProfReader from LLVM to read
instrumentation based profile data. This also switches us from the
naive text format to the binary format, since that's what's
implemented in the reader.
llvm-svn: 206658
The frontend option -fno-optimize-sibling-calls resolves to -cc1's
-mdisable-tail-calls, which is passed to the TargetMachine in the
backend. PassManagerBuilder was adding the -tailcallelim pass anyway.
Use a new DisableTailCalls option in PassManagerBuilder to disable tail
calls harder.
Requires the matching commit in LLVM that adds DisableTailCalls.
<rdar://problem/16050591>
llvm-svn: 206543
My first attempt to make sure HFAs were contiguous was in the block dealing
with padding registers, which meant it only triggered on the first stack-based
HFA. This should extend it to the rest as well.
Another part of PR19432.
llvm-svn: 206456
specializations collect all arguments and not just the ones from the
class template partial specialization from which this class template
specialization was instantiated. The debug info does not represent the
partial specialization otherwise and so specialized parameters would
go missing.
rdar://problem/16636569.
llvm-svn: 206430
Summary:
This patch adds a new flag -Rpass=. The flag indicates the name
of the optimization pass that should emit remarks stating when it
made a transformation to the code.
This implements the design I proposed in:
https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing
Other changes:
- Add DiagnosticIDs::isRemark(). Use it in printDiagnosticOptions to
print "-R" instead of "-W" in the diagnostic message.
- In BackendConsumer::OptimizationRemarkHandler, get a SourceLocation
object out of the file name, line and column number. Use that location
in the call to Diags.Report().
- When -Rpass is used without debug info a note is emitted alerting
the user that they need to use -gline-tables-only -gcolumn-info to
get this information.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3226
llvm-svn: 206401
The function hash should change when control flow changes. This patch
hashes the type of each AST node that affects counters, rather than just
counting how many there are. These types are combined into a small
enumerator that currently has 16 values.
The new hash algorithm packs the enums for consecutively visited types
into a `uint64_t`. In order to save space for new types, the types are
assumed to be 6-bit values (instead of 4-bit). In order to minimize
overhead for functions with little control flow, the `uint64_t` is used
directly as a hash if it never fills up; if it does, it's passed through
an MD5 context.
<rdar://problem/16435801>
llvm-svn: 206397
This adds a warning that triggers when profile data doesn't match for
the source that's being compiled with -fprofile-instr-use=. This fires
only once per translation unit, as warning on every mismatched
function would be quite noisy.
llvm-svn: 206322
Sema does have a CUDALaunchBoundsAttr, but CodeGen was doing nothing with it.
This change translates CUDALaunchBoundsAttr to maxntidx and minctasm
metadata, which NVPTX then translates to the correct PTX directives.
Patch by Manjunath Kudlur.
llvm-svn: 206302
This implements clause C.8 of the AAPCS in the front-end, so that Clang
accurately knows when the registers run out and it has to insert padding before
the stack objects begin.
PR19432.
llvm-svn: 206296
CapturedStmt was being ignored by instrumentation based profiling, and
its counters attributed to the containing function. Instead, we need
to treat this as a top level entity, like we do with blocks.
llvm-svn: 206231
for CXXGlobalInit/Dtor helper functions.
This makes _GLOBAL__I_a regain its DW_AT_high/low_pc in the debug info.
Thanks to echristo for catching this!
llvm-svn: 206088
Until now we were generating duplicate counters for lambdas: one set
in the function where the lambda was declared and another for the
lambda itself. Instead, we should skip over the bodies of lambdas in
their containing contexts.
llvm-svn: 206081
Fixes a bug where unsigned numbers are read using strtol and strtoll.
I don't have a testcase because this bug is effectively unobservable
right now. To expose the problem in the hash, we would need a function
with greater than INT64_MAX counters, which we don't handle anyway. To
expose the problem in the function count, we'd need a function with
greater than INT32_MAX counters; this is theoretically observable, but
it isn't a practical testcase to check in.
An upcoming commit changes the hash to be non-trivial, so we'll get some
coverage eventually.
<rdar://problem/16435801>
llvm-svn: 206001
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
llvm-svn: 205999
Emitting the PGO initialization in EmitGlobalFunctionDefinition is
inefficient, since this only has an effect once per module. We move
this to Release() with the rest of the once-per-module logic.
llvm-svn: 205977
sure that a debugger can find them when stepping through code,
for example from the included testcase:
12 int test_it() {
13 c = 1;
14 d = 2;
-> 15 a = 4;
16 return (c == 1);
17 }
18
(lldb) p a
(int) $0 = 2
(lldb) p c
(int) $1 = 2
(lldb) p d
(int) $2 = 2
and a, c, d are all part of the file static anonymous union:
static union {
int c;
int d;
union {
int a;
};
struct {
int b;
};
};
Fixes PR19221.
llvm-svn: 205952
If we crash, we raise a crash handler dialog, and that's really
annoying. Even though we can't emit correct IR until we have musttail,
don't crash.
llvm-svn: 205948
It is very similar to GCC's __PRETTY_FUNCTION__, except it prints the
calling convention.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D3311
llvm-svn: 205780
We already got the type alias correct (though I've included a test case
here) since Clang represents that like any other typedef - but type
alias templates weren't being handled.
llvm-svn: 205691
While the folding set would deduplicate the nodes themselves and LLVM
would handle not emitting the same global twice, it still meant creating
a long/redundant list of global variables.
llvm-svn: 205668
See the comment for CodeGenFunction::tryEmitAsConstant that describes
how in some contexts (lambdas) we must not emit references to the
variable, but instead use the constant directly - because of this we end
up emitting a constant for the variable, as well as emitting the
variable itself.
Should we just skip putting the variable on the stack at all and omit
the debug info for the constant? It's not clear to me - what if the
address of the local is taken?
llvm-svn: 205651
If all of our weights are zero when calculating branch weights, it
means we haven't profiled the code in question. Avoid creating a
metadata node that says all branches are equally likely in this case.
The test also checks constructs that hit the other createBranchWeights
overload. These were already working.
llvm-svn: 205606
Summary:
MSVC always emits inline functions marked with the extern storage class
specifier. The result is something similar to the opposite of
__attribute__((gnu_inline)).
This extension is also available in C.
This fixes PR19264.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3207
llvm-svn: 205485
This was committed 4 years ago in 108916 with insufficient testing to
explain why the "getTypeAsWritten" case was appropriate. Experience says
that it isn't - the presence or absence of an explicit instantiation
declaration was causing this code to generate either i<int> or i<int,
int>.
That didn't seem to be a useful distinction, and omitting the template
arguments was destructive to debuggers being able to associate the two
types across translation units or across compilers (GCC, reasonably,
never omitted the arguments).
llvm-svn: 205447
We don't want to encourage the code to emit a lexical block for
a function that needs one in order for the line table to change,
we need to grab the line information from the body of the pattern
that we were instantiated from, this code should do that.
Modify the test case to ensure that we're still looking in the
right place for all of the scopes and also that we haven't
created a lexical block where we didn't need one.
llvm-svn: 205368
Clang implements the part of the ARM ABI saying that certain functions
(e.g., constructors and destructors) return "this", but Apple's version of
gcc and llvm-gcc did not. The libstdc++ dylib on iOS 5 was built with
llvm-gcc, which means that clang cannot safely assume that code from the C++
runtime will correctly follow the ABI. It is also possible to run into this
problem when linking with other libraries built with gcc or llvm-gcc. Even
though there is no way to reliably detect that situation, it is most likely
to come up when targeting older versions of iOS. Disabling the optimization
for any code targeting iOS 5 solves the libstdc++ problem and has a reasonably
good chance of fixing the issue for other older libraries as well.
<rdar://problem/16377159>
llvm-svn: 205272
Summary:
The definition of a type later in a translation unit may change it's
type from {}* to (%struct.foo*)*. Earlier function definitions may use
the former while more recent definitions might use the later. This is
fine until they interact with one another (like one calling the other).
In these cases, a bitcast is needed because the inalloca must match the
function call but the store to the lvalue which initializes the argument
slot has to match the rvalue's type.
This technique is along the same lines with what the other,
non-inalloca, codepaths perform.
This fixes PR19287.
Reviewers: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3224
llvm-svn: 205217
This adds support for the various NEON intrinsics used by
aarch64-neon-intrinsics.c (originally written for AArch64) and enables the
test.
My implementations are designed to be semantically correct, the actual code
quality looks like its a wash between the two backends, and is frequently
different (hence the large number of CHECK changes).
llvm-svn: 205210
Some ABIs and C++ libraries may make different trade-offs in how RTTI
is emitted (currently with respect to visibility and so on). This
implements one scheme, as used by ARM64.
llvm-svn: 205101
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
The peculiarities of C99 create scenario where an LLVM IR function
declaration may need to be replaced with a definition baring a different
type because the prototype and definition are not required to agree.
However, we were not properly deferring this when it occurred.
This fixes PR19280.
llvm-svn: 205099
-u behaviour is apparently not portable between linkers (see cfe-commits
discussions for r204379 and r205012). I've moved the logic to IRGen,
where it should have been in the first place.
I don't have a Linux system to test this on, so it's possible this logic
*still* doesn't pull in the instrumented profiling runtime on Linux.
I'm in the process of getting tests going on the compiler-rt side
(llvm-commits "[PATCH] InstrProf: Add initial compiler-rt test"). Once
we have tests for the full flow there, the runtime logic should get a
whole lot less brittle.
<rdar://problem/16458307>
llvm-svn: 205023
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
This produces valid IR now that llvm rejects aliases to weak aliases and warns
the user that the resolution is not changed if the weak alias is overridden.
llvm-svn: 204935
instead of rolling an inefficient version of the function. This
changes some order of emission of metadata nodes, fix up those
testcases and make them more flexible to some changes.
llvm-svn: 204874
This commit fixes a cast instruction assertion failure
due to the incompatible type cast. This will only happen when
the target requires atomic libcalls.
llvm-svn: 204834
The main difference between __va_start and __builtin_va_start is that
the address of the va_list has already been taken, and the va_list is
always a char*.
__va_end and __va_arg are not needed.
llvm-svn: 204821
Conceptually one of these loops is just a while-loop, but the actual code-gen
is more complicated. We don't instrument all the different control flow edges
to get accurate counts for each conditional branch, nor do I think it makes
sense to do so. Instead, make the simplifying assumption that the loop behaves
like a while-loop. Use the same branch weights for the first check for an
empty collection as would be used for the back-edge of a while loop, and use
that same weighting for the innermost loop, ignoring the possibility that there
may be some extra code to go fetch more elements.
llvm-svn: 204767
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date. Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.
This reverts commit r204596.
llvm-svn: 204675
This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
"special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.
Thanks to Richard Smith for pointing these out!
llvm-svn: 204586
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.
llvm-svn: 204562
location that the next call emitLocation() would default to. Otherwise
setLocation() may wrongly believe that the current source file didn't
change, when in fact it did.
llvm-svn: 204517
Variables with available_externally linkage can be dropped at will.
This causes link errors, since there are still references to the
instrumentation! linkonce_odr is almost equivalent, so use that
instead.
As a drive-by fix (I don't have an Elf system, so I'm not sure how to
write a testcase), use linkonce linkage for the instrumentation of
extern_weak functions.
<rdar://problem/15943240>
llvm-svn: 204408
The variable is used to set the linkage for variables, and will become
different from function linkage in a follow-up commit.
<rdar://problem/15943240>
llvm-svn: 204407
These functions are in the profile runtime. PGO comes later.
Unfortunately, there's only room for 16 characters in a Darwin section,
so use __llvm_prf_ instead of __llvm_profile_ for section names.
<rdar://problem/15943240>
llvm-svn: 204390
Remove the remaining explicit static initialization from translation
units, at least on Darwin. Instead, create a use of __llvm_pgo_runtime,
which will pull in required code from compiler-rt.
After this commit (and its pair in compiler-rt), a user can define their
own __llvm_pgo_runtime to satisfy this undefined symbol and call the
functions in compiler-rt directly.
<rdar://problem/15943240>
llvm-svn: 204379
The hash itself is still the number of counters, which isn't all that
useful, but this separates the API changes from the actual
implementation of the hash and will make it easier to transition to
the ProfileData library once it's implemented.
llvm-svn: 204186
In instrumentation-based profiling, we need a set of data structures to
represent the counters. Previously, these were built up during static
initialization. Now, they're shoved into a specially-named section so
that they show up as an array.
As a consequence of the reorganizing symbols, instrumentation data
structures for linkonce functions are now correctly coalesced.
This is the first step in a larger project to minimize runtime overhead
and dependencies in instrumentation-based profilng. The larger picture
includes removing all initialization overhead and making the dependency
on libc optional.
<rdar://problem/15943240>
llvm-svn: 204080
data members by addition of CXXDefaultInitExpr node to the initializer expression,
it has broken treatment of arc code for such initializations. Reviewed by John McCall.
// rdar://16299964
llvm-svn: 203935
Drive-by fixing some incorrect types where a for loop would be improperly using ObjCInterfaceDecl::protocol_iterator. No functional changes in these cases.
llvm-svn: 203842
This makes Clang take advantage of the recent IR addition of a
"failure" memory ordering requirement. As with the "success" ordering,
we try to emit just a single version if the expression is constant,
but fall back to runtime detection (to allow optimisation across
function-call boundaries).
rdar://problem/15996804
llvm-svn: 203837
Rafael Espindola