Instead of checking at code generation time for each ScopStmt if a scalar has
external uses, we just iterate over the ScopArrayInfo descriptions we have and
check each of these for possible external uses.
Besides being somehow clearer, this approach has the benefit that we will always
create valid LLVM-IR even in case we disable the code generation of ScopStmt
bodies e.g. for testing purposes.
llvm-svn: 250608
ValueObjectPrinter can now mask out pointer values during a printout; also, it supports helper functions to print declarations in different formats if needed
Practically speaking however, this change is NFC as nothing yet uses it in the codebase
llvm-svn: 250599
Instead of specifically creating .plt entries for weak undef symbols, mirror
the logic in r250584, and use canBePreempted to determine is a REL24 relocation
needs a .plt entry. This might cause relocateOne to be called for a weak undef
symbol, with a REL24 relocation, but ignore this as a special case (this will
cause SA == 0, which won't happen under any other circumstance).
llvm-svn: 250597
This property was already used in the code path when no liveness
intervals are present. Unfortunately the code path that uses liveness
intervals tried to query a cached live interval for an allocatable
physreg, those are usually not computed so a conservative default was
used.
This doesn't affect any of the lit testcases. This is a foreclosure to
upcoming changes which should be NFC but without this patch this tidbit
wouldn't be NFC.
llvm-svn: 250596
This should not change behaviour because as far as I can see all code
reading the pressure changes has no effect if the PressureInc is 0.
Removing these entries however does avoid unnecessary computation, and
results in a more stable debug output. I want the stable debug output to
check that some upcoming changes are indeed NFC and identical even at
the debug output level.
llvm-svn: 250595
Summary:
This is a temporary hack until we get around to remapping the vreg
numbers to local numbers. Dead vregs cause bad numbering and make
consumers sad.
We could also just look at debug info an use named locals instead, but
vregs have to work properly anyways so there!
Reviewers: binji, sunfish
Subscribers: jfb, llvm-commits, dschuff
Differential Revision: http://reviews.llvm.org/D13839
llvm-svn: 250594
During the initial template parse for this code, 'member' is unresolved
and we don't know anything about it:
struct A { int member };
template <typename T>
struct B : public T {
using T::member;
static void f() {
(void)member; // Could be static or non-static.
}
};
template class B<A>;
The pattern declaration contains an UnresolvedLookupExpr rather than an
UnresolvedMemberExpr because `f` is static, and `member` should never be
a field. However, if the code is invalid, it may become a field, in
which case we should diagnose it.
Reviewers: rjmccall, rsmith
Differential Revision: http://reviews.llvm.org/D6700
llvm-svn: 250592
This avoids problems with different (u)intXX definition on different
platforms. Specifically this fixes a case on OS/X which had uint64_t
defined as unsigned long long.
llvm-svn: 250589
Summary:
Some shared code for handling eh.exceptionpointer and eh.exceptioncode
needs to not share the part that truncates to 32 bits, which is intended
just for exception codes.
Reviewers: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13747
llvm-svn: 250588
There is sometimes no need to generate relocation via PLT.
Example - when symbol is not undefined and we are not creating shared library. Then we can create relative relocation instead of referencing and creating PLT records.
Differential Revision: http://reviews.llvm.org/D13835
llvm-svn: 250584
Our previous value of "16 + 8 + MaxCallFrameSize" for ParentFrameOffset
is incorrect when CSRs are involved. We were supposed to have a test
case to catch this, but it wasn't very rigorous.
The main effect here is that calling _CxxThrowException inside a
catchpad doesn't immediately crash on MOVAPS when you have an odd number
of CSRs.
llvm-svn: 250583
This lets us make guesses about symbols in third party DLLs without
debug info, like MSVCR120.dll or kernel32.dll. dbghelp does the same
thing.
llvm-svn: 250582
via -fmodule-file= to be turned off; in that case, just include the relevant
files textually. This allows module files to be unconditionally passed to all
compile actions via CXXFLAGS, and to be ignored for rules that specify custom
incompatible flags.
llvm-svn: 250577
Changing PGO data format layout can be a pain. Many different places need
to be touched and kept in sync. Failing to do so usually results in errors
very time consuming to debug.
This file is intended to be the master file that defines the layout of the
core runtime data structures. Currently only two structure is covered: Per
function ProfData structure and the function record structure used in
coverage mapping.
No client code has been made yet, so this commit is NFC.
llvm-svn: 250574
In order to resolve PR25059, we're going to need to be able to generate symlinks to libraries manually, so I need this code to be reusable.
llvm-svn: 250573
If one file is MIPS64EL, all files are MIPS64EL, and vice versa.
We do not have to look up MIPS-ness for each file. Currently we
do not support 64-bit MIPS, so the config value is always false.
llvm-svn: 250566
This patch introduces a well defined header struct
to represent raw profile header instead of using raw array.
Previously the raw array is used in two different files and
is very error prone when header structure is re-organized.
This is a small cleanup with NFC.
llvm-svn: 250561
The motivation for this patch starts with PR20134:
https://llvm.org/bugs/show_bug.cgi?id=20134
void foo(int *a, int i) {
a[i] = a[i+1] + a[i+2];
}
It seems better to produce this (14 bytes):
movslq %esi, %rsi
movl 0x4(%rdi,%rsi,4), %eax
addl 0x8(%rdi,%rsi,4), %eax
movl %eax, (%rdi,%rsi,4)
Rather than this (22 bytes):
leal 0x1(%rsi), %eax
cltq
leal 0x2(%rsi), %ecx
movslq %ecx, %rcx
movl (%rdi,%rcx,4), %ecx
addl (%rdi,%rax,4), %ecx
movslq %esi, %rax
movl %ecx, (%rdi,%rax,4)
The most basic problem (the first test case in the patch combines constants) should also be fixed in InstCombine,
but it gets more complicated after that because we need to consider architecture and micro-architecture. For
example, AArch64 may not see any benefit from the more general transform because the ISA solves the sexting in
hardware. Some x86 chips may not want to replace 2 ADD insts with 1 LEA, and there's an attribute for that:
FeatureSlowLEA. But I suspect that doesn't go far enough or maybe it's not getting used when it should; I'm
also not sure if FeatureSlowLEA should also mean "slow complex addressing mode".
I see no perf differences on test-suite with this change running on AMD Jaguar, but I see small code size
improvements when building clang and the LLVM tools with the patched compiler.
A more general solution to the sext(add nsw(x, C)) problem that works for multiple targets is available
in CodeGenPrepare, but it may take quite a bit more work to get that to fire on all of the test cases that
this patch takes care of.
Differential Revision: http://reviews.llvm.org/D13757
llvm-svn: 250560
When we have a R_PPC64_ADDR64 for a weak undef symbol, which thus resolves to
0, and we're creating a shared library, we need to make sure that it stays 0
(because code that conditionally calls the weak function tests for this).
Unfortunately, we were creating a R_PPC64_RELATIVE for these relocation
targets, making the address of the undefined weak symbol equal to the base
address of the shared library (which is non-zero). In general, we should not be
creating RelativeReloc relocs for undef weak symbols.
llvm-svn: 250558
Crashing is bad, m'kay? Fixing a 4 year old bug of my own creation.
Adding the testcase now which I should have added then which would have
long since caught this.
The problem is that printMessage() will display the diagnostic but not
set HadError to true, resulting in the assembler continuing on its way
and trying to create relocations for things that may not allow them or
otherwise get itself into trouble. Using the Error() helper function
here rather than calling printMessage() directly resolves this.
rdar://23133240
llvm-svn: 250557
Tobias Grosser