Fast register pressure tracking currently only takes effect during
bottom up scheduling. Forcing this is a bit faster and simpler for
targets that don't have many scheduling constraints and don't need
top-down scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190014 91177308-0d34-0410-b5e6-96231b3b80d8
If the instruction window is < NumRegs/2, pressure tracking is not
likely to be effective. The scheduler has to process a very large
number of tiny blocks. We want this to be fast.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189991 91177308-0d34-0410-b5e6-96231b3b80d8
Register pressure tracking is half the complexity of the
scheduler. It's useful to be able to turn it off for compile time and
performance comparisons.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189987 91177308-0d34-0410-b5e6-96231b3b80d8
'Force' values in registers using the calling convention. Now, we only depend on
the calling convention and that the allocator performs copy coalescing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189985 91177308-0d34-0410-b5e6-96231b3b80d8
These instructions, such as vmul.f32, require the second source operand to
be in D0-D15 rather than the full D0-D31. When optimizing, make sure to
account for that by constraining the register class of a replacement virtual
register to be compatible with the virtual register(s) it's replacing.
I've been unsuccessful in creating a non-fragile regression test. This issue
was detected by the LLVM nightly test suite running on an A15 (Bullet).
PR17093: http://llvm.org/bugs/show_bug.cgi?id=17093
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189972 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r189886.
I found a corner case where this optimization is not valid:
Say we have a "linkonce_odr unnamed_addr" in two translation units:
* In TU 1 this optimization kicks in and makes it hidden.
* In TU 2 it gets const merged with a constant that is *not* unnamed_addr,
resulting in a non unnamed_addr constant with default visibility.
* The static linker rules for combining visibility them produce a hidden
symbol, which is incorrect from the point of view of the non unnamed_addr
constant.
The one place we can do this is when we know that the symbol is not used from
another TU in the same shared object, i.e., during LTO. I will move it there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189954 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is needed so we can use generic columnWidthUTF8 in clang-format on
win32 simultaneously with a separate system-dependent implementations of
isPrint/columnWidth in TextDiagnostic.cpp to avoid attempts to print Unicode
characters using narrow-character interfaces (which is not supported on Windows,
and we'll have to figure out how to handle this).
Reviewers: jordan_rose
Reviewed By: jordan_rose
CC: llvm-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1559
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189952 91177308-0d34-0410-b5e6-96231b3b80d8
For example, r189780's SparcISelLowering.cpp has the size 98304. It crashed clang to touch a null terminator on cygwin.
FIXME: It's not good to hardcode 4096 here. dwPageSize shows 4096.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189939 91177308-0d34-0410-b5e6-96231b3b80d8
This was regression from r134829. When linking we have to be conservative. If
one of the symbols has a significant address, then the result should have it
too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189935 91177308-0d34-0410-b5e6-96231b3b80d8
"(icmp op i8 A, B)" is equivalent to "(icmp op i8 (A & 0xff), B)" as a
degenerate case. Allowing this as a "masked" comparison when analysing "(icmp)
&/| (icmp)" allows us to combine them in more cases.
rdar://problem/7625728
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189931 91177308-0d34-0410-b5e6-96231b3b80d8
Even in cases which aren't universally optimisable like "(A & B) != 0 && (A &
C) != 0", the masks can make one of the comparisons completely redundant. In
this case, since we've gone to the effort of spotting masked comparisons we
should combine them.
rdar://problem/7625728
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189930 91177308-0d34-0410-b5e6-96231b3b80d8
