| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Previously the X86 backend would look for the sret attribute and handle
this for us. inalloca takes that all away, so we have to do the return
ourselves now.
llvm-svn: 202097
|
| |
|
|
|
|
|
| |
on correctly handled block layout IRGen.
// rdar://16111839
llvm-svn: 202063
|
| |
|
|
| |
llvm-svn: 202059
|
| |
|
|
|
|
|
| |
We still don't use the PGO to set branch weights for these loops, but at
least this keeps the compiler from crashing. <rdar://problem/16137778>
llvm-svn: 202002
|
| |
|
|
|
|
|
|
| |
that the optimizer does not duplicate code.
Patch thanks to Marcello Maggioni!
llvm-svn: 201941
|
| |
|
|
|
|
|
| |
MSVC allows extra-qualification on member functions, it lets you repeat
the class name on the method.
llvm-svn: 201918
|
| |
|
|
|
|
|
| |
Unused variable is removed. Construction order is changed to match
declaration order.
llvm-svn: 201914
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of
existing before ASTRecordLayoutBuilder. It redundantly performed many
layout operations that are now performed by ASTRecordLayoutBuilder and
asserted that the results were the same. With the addition of support
for the MS-ABI, such as placement of vbptrs, vtordisps, different
bitfield layout and a variety of other features, CGRecordLayoutBuilder
was growing unwieldy in its redundancy.
This patch re-architects CGRecordLayoutBuilder to not perform any
redundant layout but rather, as directly as possible, lower an
ASTRecordLayout to an llvm::type. The new architecture is significantly
smaller and simpler than the CGRecordLayoutBuilder and contains fewer
ABI-specific code paths. It's also one pass.
The architecture of the new system is described in the comments. For the
most part, the new system simply takes all of the fields and bases from
an ASTRecordLayout, sorts them, inserts padding and dumps a record.
Bitfields, unions and primary virtual bases make this process a bit more
complicated. See the inline comments.
In addition, this patch updates a few lit tests due to the fact that the
new system computes more accurate llvm types than CGRecordLayoutBuilder.
Each change is commented individually in the review.
Differential Revision: http://llvm-reviews.chandlerc.com/D2795
llvm-svn: 201907
|
| |
|
|
|
|
|
|
|
|
| |
Because GCC incorrectly defines _mm_prefetch to take anything that casts
to void*, people have started using that behavior. The previous patch
that made _mm_prefetch actually take a const char * broke compatibility
with existing code. This update to the patch leaves the macro that
defines _mm_prefetch with the (void*) cast when _MSC_VER is not defined.
llvm-svn: 201901
|
| |
|
|
| |
llvm-svn: 201849
|
| |
|
|
|
|
|
|
|
|
| |
This extends the intrinsic lookup table format slightly, and adds
entries for use the shared ARM/AArch64 definitions. The benefit is
currently smaller than for the SISD intrinsics (there's more custom
code implementing this set), but a few lines are saved and there's
scope for future expansion.
llvm-svn: 201848
|