| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
subdirectory in LLVM r203065.
llvm-svn: 203067
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the remaining GlobalVariables using "\01L" and
"\01l" prefixes to use private linkage. What is strange about them is
that they currently use WeakAnyLinkage. There is no comment stating
why and that is really odd since the symbols are completely hidden, so
it doesn't make sense for them to be weak.
Clang revisions like r63329, r63408, r63770, r65761 set the linkage to
weak, but don't say why. I suspect they were just copying llvm-gcc.
In llvm-gcc I found r58599 and r56322 that set DECL_WEAK, but they
were just syncing from the apple gcc. I am not exactly sure what that
means, since the last commit to
svn://gcc.gnu.org/svn/gcc/branches/apple was in 2006, 2 years earlier.
In summary, I have no idea why weak linkage was being used :-(
To quote John McCall, "Let’s try without it and see" :-)
llvm-svn: 203059
|
| |
|
|
| |
llvm-svn: 203052
|
| |
|
|
|
|
| |
in LLVM r203046.
llvm-svn: 203047
|
| |
|
|
|
|
| |
in LLVM r203038.
llvm-svn: 203039
|
| |
|
|
|
|
| |
Fixes pr19007.
llvm-svn: 203007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The MSVC ABI appears to mangle the lexical scope into the names of
statics. Specifically, a counter is incremented whenever a scope is
entered where things can be declared in such a way that an ambiguity can
arise. For example, a class scope inside of a class scope doesn't do
anything interesting because the nested class cannot collide with
another nested class.
There are problems with this scheme:
- It is unreliable. The counter is only incremented when a previously
never encountered scope is entered. There are cases where this will
cause ambiguity amongst declarations that have the same name where one
was introduced in a deep scope while the other was introduced right
after in the previous lexical scope.
- It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}}
will make the mangling of "foo" larger than it need be because the
scope counter has been incremented many times.
Because of these problems, and practical implementation concerns. We
choose not to implement this scheme if the local static or local type
isn't visible. The mangling of these declarations will look very
similar but the numbering will make far more sense, this scheme is
lifted from the Itanium ABI implementation.
Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2953
llvm-svn: 202951
|
| |
|
|
|
|
|
| |
This simplifies my last patch a bit. No change in
functionality.
llvm-svn: 202906
|
| |
|
|
|
|
| |
types aren't needlessly built during -gmlt
llvm-svn: 202900
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fails an "isa<> used with null pointer" assert during a clang-cl
self-host on Windows. This was caused by r202769, and I'm currently
reducing a test case.
Reviewers: dblaikie
Differential Revision: http://llvm-reviews.chandlerc.com/D2944
llvm-svn: 202888
|
| |
|
|
|
|
|
|
| |
if an ivar offset load is invariant iff inside an instance method
and ivar belongs to instance method's class and one of its super class.
// rdar://16095748
llvm-svn: 202872
|
| |
|
|
|
|
| |
r202827.
llvm-svn: 202828
|
| |
|
|
|
|
| |
r202821.
llvm-svn: 202822
|
| |
|
|
|
|
| |
LLVM r202816.
llvm-svn: 202817
|
| |
|
|
|
|
|
|
|
| |
explicit template instantiation declarations
* detect out of line definitions correctly
* detect member function explicit specializations correctly
llvm-svn: 202779
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicit instantiation declaration (& always emit such a type when there's an explicit instantiation definition)
We should only have this optimization fire when the explicit
instantiation definition would cause at least one member function to be
emitted, thus ensuring that even a compiler not performing this
optimization would still emit the full type information elsewhere.
But we should also pessimize output still by always emitting the
definition when the explicit instantiation definition appears so that at
some point in the future we can depend on that information even when no
code had to be emitted in that TU. (this shouldn't happen very often,
since people mostly use explicit spec decl/defs to reduce code size -
but perhaps one day they could use it to explicitly reduce debug info
size too)
This was worth about 2% for Clang and LLVM - so not a huge win, but a
win. It looks really great for simple STL programs (include <string> and
just declare a string - 14k -> 1.4k of .dwo)
llvm-svn: 202769
|
| |
|
|
|
|
|
| |
for metadata symbols for forward referenced protocols which
are never defined. // rdar://16203115
llvm-svn: 202761
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 202755
|
| |
|
|
|
|
|
| |
This needs to modify a line table test to account for the new lexical
block created to hold the new discriminator value.
llvm-svn: 202754
|
| |
|
|
|
|
| |
Create lexical blocks with discriminator value 0 by default.
llvm-svn: 202737
|
| |
|
|
| |
llvm-svn: 202711
|
| |
|
|
|
|
| |
Allows removing #include's in LLVM while switching to std::unique_ptr.
llvm-svn: 202677
|
| |
|
|
| |
llvm-svn: 202639
|
| |
|
|
| |
llvm-svn: 202635
|
| |
|
|
| |
llvm-svn: 202625
|
| |
|
|
|
|
|
|
|
| |
When lowering a bitfield, CGRecordLowering would assign the wrong
storage type to a bitfield in some cases and trigger an assertion. In
these cases the layout was still correct, just the bitfield info was
wrong.
llvm-svn: 202562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A 'remark' is information that is not an error or a warning, but rather some
additional information provided to the user. In contrast to a 'note' a 'remark'
is an independent diagnostic, whereas a 'note' always depends on another
diagnostic.
A typical use case for remark nodes is information provided to the user, e.g.
information provided by the vectorizer about loops that have been vectorized.
This patch provides the initial implementation of 'remarks'. It includes the
actual definiton of the remark nodes, their printing as well as basic parameter
handling. We are reusing the existing diagnostic parameters which means a remark
can be enabled with normal '-Wdiagnostic-name' flags and can be upgraded to
an error using '-Werror=diagnostic-name'. '-Werror' alone does not upgrade
remarks.
This patch is by intention minimal in terms of parameter handling. More
experience and more discussions will most likely lead to further enhancements
in the parameter handling.
llvm-svn: 202475
|
| |
|
|
|
|
|
|
| |
In r201528, I changed the PGO instrumentation counter for a "do" loop to not
include the fall-through count. That fall-through count is included later, b
it means that this assertion may fail for "do" loops.
llvm-svn: 202437
|
| |
|
|
| |
llvm-svn: 202429
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This merges VFPtrInfo and VBTableInfo into VPtrInfo, since they hold
almost the same information. With that change, the vbtable mangling
code can easily be applied to vftable data and we magically get the
correct, unambiguous vftable names.
Fixes PR17748.
Reviewers: timurrrr, majnemer
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2893
llvm-svn: 202425
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In llvm the only semantic difference between internal and private is that llvm
tries to hide private globals my mangling them with a private prefix. Since
the globals changed by this patch already had the magic don't mangle marker,
there should be no change in the generated assembly.
A followup patch should then be able to drop the \01L and \01l prefixes and let
llvm mangle as appropriate.
llvm-svn: 202419
|
| |
|
|
|
|
|
| |
No functionality change. This is just an intermediate patch for changing those
global variables to use private linkage.
llvm-svn: 202409
|
| |
|
|
| |
llvm-svn: 202360
|
| |
|
|
|
|
|
| |
generation purposes.
Paired with a commit to llvm.
llvm-svn: 202334
|
| |
|
|
| |
llvm-svn: 202330
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang is using llvm::StructType::isOpaque() as a way of signaling if
we've finished record type conversion in
CodeGenTypes::isRecordLayoutComplete(). However, Clang was setting the
body of the type before it finished laying out the type as a base type.
Laying out the %class.C.base LLVM type attempts to convert more types,
eventually recursively attempting to layout 'C' again, at which point we
would say that layout was complete, even though we were still in the
middle of it.
By not setting the body, we correctly signal that layout is not
complete, and things work as expected.
At some point, it might be worth refactoring this to avoid looking at
the LLVM IR types under construction.
llvm-svn: 202320
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch the globals were created with the wrong linkage and patched
afterwards. From the comments it looks like something would complain about
having an internal GV with no initializer. At least in clang the verifier will
only run way after we set the initializer, so that is not a problem.
This patch should be a nop. It just figures out the linkage earlier and
converts the old calls to setLinkage to asserts. The only case where that is
not possible is when we first see a weak import that is then implemented. In
that case we have to change the linkage, but that is the only setLinkage left.
llvm-svn: 202305
|
| |
|
|
|
|
|
| |
The table is always 128-bit so there's no reason to specify it every time we
want the intrinsic.
llvm-svn: 202259
|
| |
|
|
| |
llvm-svn: 202254
|
| |
|
|
| |
llvm-svn: 202238
|
| |
|
|
| |
llvm-svn: 202237
|
| |
|
|
| |
llvm-svn: 202219
|
| |
|
|
| |
llvm-svn: 202208
|
| |
|
|
|
|
|
|
| |
Paired commit with LLVM.
rdar://problem/13690847
llvm-svn: 202185
|
| |
|
|
| |
llvm-svn: 202170
|
| |
|
|
|
|
|
|
|
| |
The 'f' modifier is designed for integer type arguments really (according to
its documentation). It's better to use the "half width, same number" modifier.
Should be no user-visible change.
llvm-svn: 202152
|
| |
|
|
| |
llvm-svn: 202151
|
| |
|
|
|
|
|
| |
This comment survived the transition from ForceInline to InlineAlways,
fix it.
llvm-svn: 202133
|
| |
|
|
|
|
|
|
|
|
| |
The __forceinline keyword's semantics are now recast as AlwaysInline and
the kw___forceinline token has its language mode set for KEYMS.
This preserves the semantics of the previous implementation but with
less duplication of code.
llvm-svn: 202131
|
| |
|
|
|
|
|
|
|
| |
Take advantage of CharUnits::alignmentAtOffset instead of calculating it
by hand.
Differential Revision: http://llvm-reviews.chandlerc.com/D2862
llvm-svn: 202098
|