| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We collect a maximal function count among all functions in the pgo data file.
For functions that are hot, we set its InlineHint attribute. For functions that
are cold, we set its Cold attribute.
We currently treat functions with >= 30% of the maximal function count as hot
and functions with <= 1% of the maximal function count are treated as cold.
These two numbers are from preliminary tuning on SPEC.
This commit should not affect non-PGO builds and should boost performance on
instrumentation based PGO.
llvm-svn: 200874
|
| |
|
|
| |
llvm-svn: 200861
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Member pointers are mangled as they would be represented at runtime.
They can be a single integer literal, single decl, or a tuple with some
more numbers tossed in. With Clang today, most of those numbers will be
zero because we reject pointers to members of virtual bases.
This change required moving VTableContextBase ownership from
CodeGenVTables to ASTContext, because mangling now depends on vtable
layout.
I also hoisted the inheritance model helpers up to be inline static
methods of MSInheritanceAttr. This makes the AST code that deals with
member pointers much more readable.
MSVC doesn't appear to have stable manglings of null member pointers:
- Null data memptrs in function templates have a mangling collision with
the first field of a non-polymorphic single inheritance class.
- The mangling of null data memptrs changes if you add casts.
- Large null function memptrs in class templates crash MSVC.
Clang uses the class template mangling for null data memptrs and the
function template mangling for null function memptrs to deal with this.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2695
llvm-svn: 200857
|
| |
|
|
|
|
|
|
| |
not-yet-completed templated types. getTypeSize() needs a complete type.
rdar://problem/15931354
llvm-svn: 200797
|
| |
|
|
|
|
|
|
| |
Now that the back-end intrinsics are more regular, there's no need for the
special handling these got in the front-end, so they can be moved to
EmitCommonNeonBuiltinExpr.
llvm-svn: 200769
|
| |
|
|
| |
llvm-svn: 200711
|
| |
|
|
| |
llvm-svn: 200708
|
| |
|
|
|
|
|
| |
The LLVM backend now has invariant types on the various crypto-intrinsics,
because in all cases there's only really one interpretation.
llvm-svn: 200707
|
| |
|
|
| |
llvm-svn: 200598
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a non-trivial parameter is present, clang now gathers up all the
parameters that lack inreg and puts them into a packed struct. MSVC
always aligns each parameter to 4 bytes and no more, so this is a pretty
simple struct to lay out.
On win64, non-trivial records are passed indirectly. Prior to this
change, clang was incorrectly using byval on win64.
I'm able to self-host a working clang with this change and additional
LLVM patches.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2636
llvm-svn: 200597
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR15768, where the sret parameter and the 'this' parameter
are in the wrong order.
Instance methods compiled by MSVC never return records in registers,
they always return indirectly through an sret pointer. That sret
pointer always comes after the 'this' parameter, for both __cdecl and
__thiscall methods.
Unfortunately, the same is true for other calling conventions, so we'll
have to change the overall approach here relatively soon.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2664
llvm-svn: 200587
|
| |
|
|
|
|
|
|
| |
This should be the last routine patch: AArch64 does still delegate to
EmitARMBuiltinExpr, but the remaining instances have complications of
one sort or another so some more cunning thought will be needed.
llvm-svn: 200528
|
| |
|
|
| |
llvm-svn: 200527
|
| |
|
|
| |
llvm-svn: 200526
|
| |
|
|
| |
llvm-svn: 200525
|
| |
|
|
| |
llvm-svn: 200524
|
| |
|
|
|
|
|
| |
This extends the refactoring to the whole of the first block of
trivial correspondences (as a fairly arbitrary boundary).
llvm-svn: 200472
|
| |
|
|
|
|
|
| |
As a starting point, this moves the CodeGen for NEON permutation
instructions (vtrn, vzip, vuzp) into a new shared function.
llvm-svn: 200471
|
| |
|
|
| |
llvm-svn: 200470
|
| |
|
|
|
|
|
| |
synthesized getters for performance improvement.
// rdar://15884113
llvm-svn: 200430
|
| |
|
|
|
|
|
|
| |
grow into the following virtual base.
Differential Revision: http://llvm-reviews.chandlerc.com/D2560
llvm-svn: 200359
|
| |
|
|
|
|
|
|
|
| |
Arguments and return values must always be marshalled as for the base
AAPCS when the callee is a variadic function.
Patch by Oliver Stannard!
llvm-svn: 200307
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the last incorrect uses and templatize the function to require a
compile-time constant string preventing further misuse.
The diagnostic formatter expects well-formed input and has undefined behaviour
with arbitrary input or crafted user strings in source files. Accepting user
input would also have caused unbounded generation of new diagnostic IDs which
can be problematic in long-running sessions or language bindings.
This completes the work to fix several incorrect callers that passed user
input or raw messages to the diagnostics engine where a constant format string
was expected.
llvm-svn: 200132
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
| |
|
|
|
|
|
|
|
|
| |
might have a smaller size as compared to the stand-alone type of the base class.
This is possible when the derived class is packed and hence might have smaller
alignment requirement than the base class.
Differential Revision: http://llvm-reviews.chandlerc.com/D2599
llvm-svn: 200031
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to statement expressions supported as GCC extension, it is possible
to put 'break' or 'continue' into a loop/switch statement but outside
its body, for example:
for ( ; ({ if (first) { first = 0; continue; } 0; }); )
This code is rejected by GCC if compiled in C mode but is accepted in C++
code. GCC bug 44715 tracks this discrepancy. Clang used code generation
that differs from GCC in both modes: only statement of the third
expression of 'for' behaves as if it was inside loop body.
This change makes code generation more close to GCC, considering 'break'
or 'continue' statement in condition and increment expressions of a
loop as it was inside the loop body. It also adds error for the cases
when 'break'/'continue' appear outside loop due to this syntax. If
code generation differ from GCC, warning is issued.
Differential Revision: http://llvm-reviews.chandlerc.com/D2518
llvm-svn: 199897
|
| |
|
|
|
|
|
| |
As vcles_f32() and vcled_f64 are implemented by FCMGE, operands
should make a swap.
llvm-svn: 199866
|
| |
|
|
|
|
|
| |
This adds tests for both logical or and for logical and, which was
already correct.
llvm-svn: 199865
|
| |
|
|
| |
llvm-svn: 199864
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PNaCl and Emscripten can both handle va_arg IR instructions with
struct type.
Also add a test to cover generating a va_arg IR instruction from
va_arg in C on le32 (as already handled by VisitVAArgExpr() in
CGExprScalar.cpp), which was not covered by a test before.
(This fixes https://code.google.com/p/nativeclient/issues/detail?id=2381)
Differential Revision: http://llvm-reviews.chandlerc.com/D2539
llvm-svn: 199830
|
| |
|
|
|
|
| |
Cleanup only.
llvm-svn: 199773
|
| |
|
|
|
|
|
|
|
| |
of the current compilation unit.
As a side effect this enables many more LTO uniquing opportunities.
This reapplies r199757 with a better testcase.
llvm-svn: 199760
|
| |
|
|
| |
llvm-svn: 199758
|
| |
|
|
|
|
|
|
|
| |
of the current compilation unit.
As a side effect this enables many more LTO uniquing opportunities.
rdar://problem/15851206
llvm-svn: 199757
|
| |
|
|
| |
llvm-svn: 199709
|
| |
|
|
| |
llvm-svn: 199705
|
| |
|
|
|
|
|
|
|
| |
I misunderstood the discussion on this. The complexity here is
justified by the malloc overhead it saves.
This reverts commit r199302.
llvm-svn: 199700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without them they can be merged with non unnamed_addr constants during LTO.
The resulting constant is not unnamed_addr and goes in a different section,
which causes ld64 to crash.
A testcase that would crash before:
* file1.mm:
void g(id notification) {
[notification valueForKey:@"name"];
}
* file2.cpp:
extern const char js_name_str[] = "name";
* file3.cpp
extern bool JS_GetProperty(const char *name);
extern const char js_name_str[];
bool js_ReportUncaughtException() { JS_GetProperty(js_name_str); }
run
clang file1.mm -o file1.o -c -w -emit-llvm
clang file2.cpp -o file2.o -c -w -emit-llvm
clang file3.cpp -o file3.o -c -w
ld -dylib -o XUL file1.o file2.o file3.o -undefined dynamic_lookup.
llvm-svn: 199688
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
|
| |
|
|
|
|
| |
Thanks to David Blaikie for the push.
llvm-svn: 199685
|
| |
|
|
| |
llvm-svn: 199665
|
| |
|
|
|
|
|
|
|
| |
Currently it tracks the number of free registers, but soon it will track
stack offsets for inalloca lowering.
No functional change.
llvm-svn: 199532
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit r199475 (which reverted r199416) with fixes for the
breakages.
We wouldn't lock an inheritance model if we saw a pointer-to-member
formed as a result of the address-of operator.
llvm-svn: 199482
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It broke tests for targeting x86_64-pc-win32:
Clang Tools :: clang-modernize/LoopConvert/array.cpp
Clang :: CodeGenCXX/2010-05-10-Var-DbgInfo.cpp
Clang :: CodeGenCXX/member-call-parens.cpp
Clang :: CodeGenCXX/ptr-to-datamember.cpp
Clang :: SemaTemplate/instantiate-function-1.cpp
llvm-svn: 199475
|
| |
|
|
|
|
|
|
|
| |
class and use it pervasively to restore debug locations.
Fixes an interaction between cleanup and EH that caused the location
to not be restored properly after emitting a landing pad.
rdar://problem/15208190
llvm-svn: 199444
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MSVC ABI is rather finicky about the exact representation of it's
pointer-to-member representation. The exact position of when and where
it will go with one representation versus another appears to be when it
desires the pointer-to-member to be complete.
To properly implement this in clang, do several things:
- Give up on tracking the polymorphic nature of the class. It isn't
useful to Sema and is only pertinent when choosing CodeGen-time
details like whether the field-offset can be 0 instead of -1.
- Insist on locking-in the inheritance model when we ask our
pointer-to-member type to be complete. From there, grab the
underlying CXXRecordDecl and try to make *that* complete. Once we've
done this, we can calculate it's inheritance model and apply it using
an attribute.
N.B. My first bullet point is a lie. We will eventually care about the
specifics of whether or not a CXXRecordDecl is or is not polymorphic
because MSVC compatible mangling of such things depends on it. However,
I believe we will handle this in a rather different way.
llvm-svn: 199416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flag from clang, and disable zero-base shadow support on all platforms
where it is not the default behavior.
- It is completely unused, as far as we know.
- It is ABI-incompatible with non-zero-base shadow, which means all
objects in a process must be built with the same setting. Failing to
do so results in a segmentation fault at runtime.
- It introduces a backward dependency of compiler-rt on user code,
which is uncommon and complicates testing.
This is the Clang part of a larger change.
llvm-svn: 199372
|
| |
|
|
|
|
|
|
|
|
| |
marked as AlwaysInline or ForceInline.
This moves us to what gcc does with -fno-inline. The attribute approach
was discussed to be better than switching to InlineAlways inliner in presence
of LTO.
llvm-svn: 199324
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Way back in r129652 we tried to avoid emitting an empty block at -O0
for switch cases that did nothing but break. This led to a poor
debugging experience as reported in PR9796, so we disabled the
optimization for -O0 but left it in for higher optimization levels in
r154420.
Since the whole point of this was to improve -O0, it's silly to keep
the complexity at all.
llvm-svn: 199302
|
| |
|
|
| |
llvm-svn: 199258
|