The intent of revision r300311 was to add a check for invalid scheduling class
descriptors. However, it ended up adding a redundant call in a basic block that
should not be reachable.
llvm-svn: 327231
In C, we'll wait until the end of the scope to clean up aggregate
temporaries used for returns from calls. This means in cases like:
{
// Assuming that `Bar` is large enough to warrant indirect returns
struct Bar b = {};
b = foo(&b);
b = foo(&b);
b = foo(&b);
b = foo(&b);
}
...We'll allocate space for 5 Bars on the stack (`b`, and 4
temporaries). This becomes painful in things like large switch
statements.
If cleaning up sooner is trivial, we should do it.
llvm-svn: 327229
Summary:
There are 3 different operand orders for FMA instructions so figuring out the exact operation being performed requires a lot of thought.
This patch adds a comment to the end of the assembly line to print the exact operation.
I think I've got all the instructions in here except the ones with builtin rounding.
I didn't update all tests, but I assume we can get them as we regenerate tests in the future.
Reviewers: spatel, v_klochkov, RKSimon
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44345
llvm-svn: 327225
Summary:
r327219 adds wrappers to sort which shuffle the container before sorting.
This causes lldb bots to break as the call to sort is now ambiguous:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/20725/steps/ninja%20build%20local/logs/stdio
So we need use llvm::sort instead of sort to avoid ambiguity with std::sort.
Note: This patch is just to unbreak the bots. I plan to have subsequent patches which will convert all
calls to std::sort to llvm::sort.
Reviewers: RKSimon, k8stone, jingham, labath, zturner
Subscribers: andreadb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D44354
llvm-svn: 327224
Summary:
std::sort and array_pod_sort both use non-stable sorting algorithms.
This means that the relative order of elements with the same key is
undefined. This patch is an attempt to uncover such scenarios by
randomly shuffling all containers before sorting, if EXPENSIVE_CHECKS
is enabled.
Here's the bugzilla for this: https://bugs.llvm.org/show_bug.cgi?id=35135
Reviewers: dblaikie, dexonsmith, chandlerc, efriedma, RKSimon
Reviewed By: RKSimon
Subscribers: fhahn, davide, RKSimon, vsk, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D39245
llvm-svn: 327219
Piecewise affine expressions have directly corresponding mathematical
operators. Introduce these operators as overloads as this makes writing
code with isl::pw_aff expressions more directly readable.
We can now write:
A = B + C instead of A = B.add(C)
llvm-svn: 327216
This change removes method Backend::getProcResourceMasks() and simplifies some
logic in the Views. This effectively removes yet another dependency between the
views and the Backend.
No functional change intended.
llvm-svn: 327214
With the updated LangRef ( D44216 / rL327138 ) in place, we can proceed with more constant folding.
I'm intentionally taking the conservative path here: no matter what the constant or the FMF, we can
always fold to NaN. This is because the undef operand can be chosen as NaN, and in our simplified
default FP env, nothing else happens - NaN just propagates to the result. If we find some way/need
to propagate undef instead, that can be added subsequently.
The tests show that we always choose the same quiet NaN constant (0x7FF8000000000000 in IR text).
There were suggestions to improve that with a 'NaN' string token or not always print a 64-bit hex
value, but those are independent changes. We might also consider setting/propagating the payload of
NaN constants as an enhancement.
Differential Revision: https://reviews.llvm.org/D44308
llvm-svn: 327208
Use isInlineViable to prevent inlining of functions with non-inlinable
constructs, in case cost analysis is skipped.
Reviewers: efriedma, sfertile, davide, davidxl
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D42846
llvm-svn: 327207
This patch uses the infrastructure added in r326307 for enabling
non-trivial fields to be declared in C structs to allow __weak fields in
C structs in ARC.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D44095
llvm-svn: 327206
X86InstComments.h is used by tools that only have the MC layer. We shouldn't be importing a file from CodeGen into this.
X86InstrInfo.h isn't a great place, but I couldn't find a better one.
llvm-svn: 327202
We're persisting AliasResults in some places in MemorySSA, so the size
of these now matters a little bit (well, 8 regular-sized bits, to be
precise).
Do the same for ModRefInfo for consistency.
llvm-svn: 327201
r327100 made us stop producing vecreduce-propagate-sd-flags.s, but it's
still sticking around on some bots. This makes the bots unhappy.
I'll revert this tomorrow.
llvm-svn: 327199
This fixes pr36674.
While it is valid for shouldAssumeDSOLocal to return false anytime,
always returning false for intrinsics is not optimal on i386 and also
hits a bug in the backend.
To use a plt, the caller must first setup ebx to handle the case of
that file being linked into a PIE executable or shared library. In
those cases the generated PLT uses ebx.
Currently we can produce "calll expf@plt" without setting ebx. We
could fix that by correctly setting ebx, but this would produce worse
code for the case where the runtime library is statically linked. It
would also required other tools to handle R_386_PLT32.
llvm-svn: 327198
r327171 "Improve Dependency analysis when doing multi-node Instruction Selection"
r328170 "[DAG] Enforce stricter NodeId invariant during Instruction selection"
Reverting patch as NodeId invariant change is causing pathological
increases in compile time on PPC
llvm-svn: 327197
libFuzzer dependes on C++ library, when building for Fuchsia, we
need to ensure that libFuzzer is only being built after libc++
has been built, so we add an explicity dependency on it.
Differential Revision: https://reviews.llvm.org/D44340
llvm-svn: 327196
When the generated __config file is being used, it is currently only
copied during installation process. However, that means that the file
that gets copied into LLVM build directory is the vanilla __config file,
and any parts of the build that depend on the just built toolchain like
sanitizers will get that instead of the generated version. To avoid this
issue, we need to copy the generated header into the LLVM build
directory as well.
Differential Revision: https://reviews.llvm.org/D43797
llvm-svn: 327194
I want to extend the properties on ModuleList to also contain other
more general settings and renaming the settings category to symbols
seems to be the least bad of choices.
llvm-svn: 327193
If CodeGenFunction::EmitCall is:
- asked to emit a call with an indirectly returned value,
- given an invalid return value slot, and
- told the return value of the function it's calling is unused
then it'll make its own temporary, and add lifetime markers so that the
temporary's lifetime ends immediately after the call.
The early lifetime.end becomes problematic when we need to run a
destructor on the result of the function.
Instead of unconditionally saying that results of all calls are used
here (which would be correct, but would also cause us to never emit
lifetime markers for these temporaries), we just build our own temporary
to pass in when a dtor has to be run.
llvm-svn: 327192
These instructions have 3 operands that can be commuted. The first commute we find may not be the best. So we should keep searching if we performed an aggressive commute. There may still be an operand that is killed or a physical register constraint that might be better.
Differential Revision: https://reviews.llvm.org/D44324
llvm-svn: 327188
Updating the run-clang-tidy.py script to allow specification of the
config argument to the clang-tidy invocation.
Differential Revision: https://reviews.llvm.org/D43538
llvm-svn: 327186
by explicitly listing where we expect this test to work.
Because this test invokes undefined behaviour all sorts of things
can happen (e.g. crash, or on some bots asan manages to catch
something). The test seems to pass okay on Darwin (x86_64/x86_64/i386)
and on Linux (x86_64/i386) so explicitly require one of these platforms
to run the test.
llvm-svn: 327185
