If the DAG already has only legal types, then the second round of DAG combines
is skipped. In this case VSELECT+SETCC patterns that match a more efficient
instruction (e.g. min/max) are never recognized.
This fix allows VSELECT+SETCC combines if the types are already legal before DAG
type legalization.
Reviewer: Nadav
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190105 91177308-0d34-0410-b5e6-96231b3b80d8
expression uses an assembler temporary symbol from an assignment. In this case
the symbol does not have a fragment so the use of getFragment() would be NULL
and caused a crash. In the case of an assembler temporary symbol we want to use
the AliasedSymbol (if any) which will create a local relocation entry, but if
it is not an assembler temporary symbol then let it use that symbol with an
external relocation entry.
rdar://9356266
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190096 91177308-0d34-0410-b5e6-96231b3b80d8
ptr_to_member.
We introduce a new class DITypeRef that represents a reference to a DIType.
It wraps around a Value*, which can be either an identifier in MDString
or an actual MDNode. The class has a helper function "resolve" that
finds the actual MDNode for a given DITypeRef.
We specialize getFieldAs to return a field that is a reference to a
DIType. To correctly access the base type field of ptr_to_member,
getClassType now calls getFieldAs<DITypeRef> to return a DITypeRef.
Also add a typedef for DITypeIdentifierMap and a helper
generateDITypeIdentifierMap in DebugInfo.h. In DwarfDebug.cpp, we keep
a DITypeIdentifierMap and call generateDITypeIdentifierMap to actually
populate the map.
Verifier is updated accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190081 91177308-0d34-0410-b5e6-96231b3b80d8
This pass was segfaulting when it ran into a non-intrinsic function
call. Function calls are not supported, so now instead of segfaulting,
we will get an assertion failure with a nice error message.
I'm not sure how to test this using lit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190076 91177308-0d34-0410-b5e6-96231b3b80d8
These were pretty straightforward instructions, with some assembly support
required for HLT.
The ARM assembler is keen to split the instruction mnemonic into a
(non-existent) 'H' instruction with the LT condition code. An exception for
HLT is needed.
HLT follows the same rules as BKPT when in IT blocks, so the special BKPT
hadling code has been adapted to handle HLT also.
Regression tests added including diagnostic tests for out of range immediates
and illegal condition codes, as well as negative tests for pre-ARMv8.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190053 91177308-0d34-0410-b5e6-96231b3b80d8
Solution is not sufficient to prevent 'mov pc, lr' being emitted for jump table code.
Test case doesn't trigger the added functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190047 91177308-0d34-0410-b5e6-96231b3b80d8
This improves code generation for jump tables by avoiding the emission of "mov pc, lr" which could fool the processor into believing this is a return from a function causing mispredicts. The code generation logic for jump tables uses ADR to materialize the address of the jump target.
Patch by Daniel Stewart!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190043 91177308-0d34-0410-b5e6-96231b3b80d8
In sparc, setjmp stores only the registers %fp, %sp, %i7 and %o7. longjmp restores
the stack, and the callee-saved registers (all local/in registers: %i0-%i7, %l0-%l7)
using the stored %fp and register windows. However, this does not guarantee that the longjmp
will restore the registers, as they were when the setjmp was called. This is because these
registers may be clobbered after returning from setjmp, but before calling longjmp.
This patch prevents the registers %i0-%i5, %l0-l7 to live across the setjmp call using the register mask.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190033 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
This reverts commit r189913.
Talked with Eric on IRC. I am going to XFAIL the failing test since it
is using what Eric described as "the member hack" which was needed on
that old GDB.
Sorry for the noise!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189914 91177308-0d34-0410-b5e6-96231b3b80d8
Iterator of std::vector may be implemented as a raw pointer. In
this case begin iterators are rvalues and cannot be incremented.
For example, this is the case with STDCXX implementation of vector.
Patch by Konstantin Tokarev <annulen@yandex.ru>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189911 91177308-0d34-0410-b5e6-96231b3b80d8
Original message:
If a constant or a function has linkonce_odr linkage and unnamed_addr, mark
hidden. Being linkonce_odr guarantees that it is available in every dso that
needs it. Being a constant/function with unnamed_addr guarantees that the
copies don't have to be merged.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189886 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the clang crash handling code would kick in and give a crash
report for these, even though they're not that sort of error.
rdar://14882264
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189878 91177308-0d34-0410-b5e6-96231b3b80d8
The reason that I am turning off this optimization is that there is an
additional case where a block can escape that has come up. Specifically, this
occurs when a block is used in a scope outside of its current scope.
This can cause a captured retainable object pointer whose life is preserved by
the objc_retainBlock to be deallocated before the block is invoked.
An example of the code needed to trigger the bug is:
----
\#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
void (^somethingToDoLater)();
{
NSObject *obj = [NSObject new];
somethingToDoLater = ^{
[obj self]; // Crashes here
};
}
NSLog(@"test.");
somethingToDoLater();
return 0;
}
----
In the next commit, I remove all the dead code that results from this.
Once I put in the fixing commit I will bring back the tests that I deleted in
this commit.
rdar://14802782.
rdar://14868830.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189869 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes the default setting for the LateVectorization flag that controls where the loop-vectorizer is ran.
Perf gains:
SingleSource/Benchmarks/Shootout/matrix -37.33%
MultiSource/Benchmarks/PAQ8p/paq8p -22.83%
SingleSource/Benchmarks/Linpack/linpack-pc -16.22%
SingleSource/Benchmarks/Shootout-C++/ary3 -15.16%
MultiSource/Benchmarks/TSVC/NodeSplitting-flt/NodeSplitting-flt -10.34%
MultiSource/Benchmarks/TSVC/NodeSplitting-dbl/NodeSplitting-dbl -7.12%
Regressions:
SingleSource/Benchmarks/Misc/lowercase 15.10%
MultiSource/Benchmarks/TSVC/Equivalencing-flt/Equivalencing-flt 13.18%
SingleSource/Benchmarks/Shootout-C++/matrix 8.27%
SingleSource/Benchmarks/CoyoteBench/lpbench 7.30%
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189858 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r189648.
Fixes for the previously failing clang-side arm_neon_intrinsics test
cases will be checked in separately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189841 91177308-0d34-0410-b5e6-96231b3b80d8
This won't affect the kinds of hashes we test for as we actually
do hashing based on form and attribute. Change the fission-hash
testcase one last time to handle DW_AT_comp_dir.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189840 91177308-0d34-0410-b5e6-96231b3b80d8
1) If the width of vectorization list candidate is bigger than vector reg width, we will break it down to fit the vector reg.
2) We do not vectorize the width which is not power of two.
The performance result shows it will help some spec benchmarks. mesa improved 6.97% and ammp improved 1.54%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189830 91177308-0d34-0410-b5e6-96231b3b80d8
For now this just handles simple comparisons of an ANDed value with zero.
The CC value provides enough information to do any comparison for a
2-bit mask, and some nonzero comparisons with more populated masks,
but that's all future work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189819 91177308-0d34-0410-b5e6-96231b3b80d8
Select condition shadow was being ignored resulting in false negatives.
This change OR-s sign-extended condition shadow into the result shadow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189785 91177308-0d34-0410-b5e6-96231b3b80d8
What we really want is to enable Swift by default for *v7s triples (and there already seems to be some logic which attempts to do that). In that case the iOS version doesn't matter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189763 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements vector support for select instruction and adds specific vector instructions : shuffle and insertelement. (tests are also included)
and functions lle_X_memset, lle_X_memcpy added.
Done by Veselov, Yuri (mailto:Yuri.Veselov@intel.com)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189735 91177308-0d34-0410-b5e6-96231b3b80d8
printing routine. This is made harder to see due to the surprising
formatting, inconsistent brace usage, and repeated conditions that all
test the same thing.
The only "consequence" of this bug is re-assigning 'str' to an empty
string when computing the error string for an error number of 0 in the
event of a non-GNU strerror_r routine. So, nothing to see here other
than cleanup. It did help me find PR17055 in clang-format though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189734 91177308-0d34-0410-b5e6-96231b3b80d8
don't exist in libc. This is really not the right way to solve this problem;
but it's not clear to me at this time exactly what is the right way.
If we create stubs here, they will cause link errors because these functions
do not exist in libc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189727 91177308-0d34-0410-b5e6-96231b3b80d8
The existing code missed some edge cases when e.g. we're going to emit sqrtf but
only the availability of sqrt was checked. This happens on odd platforms like
windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189724 91177308-0d34-0410-b5e6-96231b3b80d8
There was one case that we could hit a DebugValue where I didn't think
to check. DebugValues are evil. No checkinable test case, sorry. It's
an obvious fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189717 91177308-0d34-0410-b5e6-96231b3b80d8
Here are a few miscellaneous things to tidy up the PPC64 fast-isel
implementation. I corrected a couple of commentary lapses, and added
documentation of future opportunities. I also implemented
TargetMaterializeAlloca, which I somehow forgot when I split up the
original huge patch.
Finally, I decided to delete SelectCmp. I hadn't previously hooked it
in to TargetSelectInstruction(), and when I did I realized it wasn't
serving any useful purpose. This is only useful for compares that
don't feed a branch in the same block, and to handle that we would
have to have logic to interpret i1 as a condition register. This
could probably be done, but would require Unseemly Hackery, and
honestly does not seem worth the hassle.
This ends the current patch series.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189715 91177308-0d34-0410-b5e6-96231b3b80d8
This is the last substantive patch I'm planning for fast-isel in the
near future, adding fast selection of integer truncates. There are
certainly more things that can be improved (many of which are called
out in FIXMEs), but for now we are catching most of the important
cases.
I'll document some of the remaining work in a cleanup patch shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189706 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds fast-isel support for calls (but not intrinsic calls
or varargs calls). It also removes a badly-formed assert. There are
some new tests just for calls, and also for folding loads into
arguments on calls to avoid extra extends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189701 91177308-0d34-0410-b5e6-96231b3b80d8
- We do some nasty things w.r.t. installing or overriding signal handlers in
order to improve our crash recovery support or interaction with crash
reporting software, and those things are not necessarily appropriate when
LLVM is being linked into a client application that has its own ideas about
how to do things. This gives those clients a way to disable that handling at
build time.
- Currently, the code this guards is all Apple specific, but other platforms
might have the same concerns so I went for a more generic configure
name. Someone who is more familiar with library embedding on Windows can
handle choosing which of the Windows/Signals.inc behaviors might make sense
to go under this flag.
- This also fixes the proper autoconf'ing of ENABLE_BACKTRACES. The code
expects it to be undefined when disabled, but the autoconf check was just
defining it to 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189694 91177308-0d34-0410-b5e6-96231b3b80d8
has hard float, when you compile the mips32 code you have to make sure
that it knows to compile any mips32 routines as hard float. I need to clean
up the way mips16 hard float is specified but I need to first think through
all the details. Mips16 always has a form of soft float, the difference being
whether the underlying hardware has floating point. So it's not really
necessary to pass the -soft-float to llvm since soft-float is always true
for mips16 by virtue of the fact that it will not register floating point
registers. By using this fact, I can simplify the way this is all handled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189690 91177308-0d34-0410-b5e6-96231b3b80d8
Yet another chunk of fast-isel code. This one handles various
conversions involving floating-point. (It also includes some
miscellaneous handling throughout the back end for LWA_32 and LWAX_32
that should have been part of the load-store patch.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189677 91177308-0d34-0410-b5e6-96231b3b80d8
PR17026. Also avoid undefined shifts and shift amounts larger than 64 bits
(those are always undef because we can't represent integer types that large).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189672 91177308-0d34-0410-b5e6-96231b3b80d8
This removes all expensive pressure tracking logic from the scheduling
critical path of node comparison.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189643 91177308-0d34-0410-b5e6-96231b3b80d8
Only compare pressure within the same set. When multiple sets are
affected, we prioritize the most constrained set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189641 91177308-0d34-0410-b5e6-96231b3b80d8
Created SUPressureDiffs array to hold the per node PDiff computed during DAG building.
Added a getUpwardPressureDelta API that will soon replace the old
one. Compute PressureDelta here from the precomputed PressureDiffs.
Updating for liveness will come next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189640 91177308-0d34-0410-b5e6-96231b3b80d8
Mostly trivial patch adding support for compares. The meat of the
work was added with the branch support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189639 91177308-0d34-0410-b5e6-96231b3b80d8
This is the next big chunk of fast-isel code. The primary purpose is
to implement selection of loads and stores, but there is a lot of
drag-along to support this. The common code to analyze addresses for
both loads and stores is substantial. It's also necessary to add the
materialization code for global values.
Related to load-store processing is the code to fold loads into
integer extends, since otherwise we generate lots of redundant
instructions. We also need to add some overrides to some FastEmit
routines to ensure we don't assign GPR 0 to a virtual register when
this would change the meaning of an instruction.
I added handling selection of a few binary arithmetic instructions, to
enable committing some test cases I wrote a while back.
Finally, ap couple of miscellaneous changes:
* I cleaned up some poor style from a previous patch in
PPCISelLowering.cpp, pointed out by David Blaikie.
* I enlarged the Addr.Offset field to avoid sign problems with 32-bit
offsets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189636 91177308-0d34-0410-b5e6-96231b3b80d8
This is a re-commit of r189442; I'll follow up with clang changes.
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189624 91177308-0d34-0410-b5e6-96231b3b80d8
createClassType, createStructType, createUnionType, createEnumerationType,
and createForwardDecl will retain a type when created with a unique identifier,
to make sure they are treated as used even when all uses are replaced with
the identifiers.
Use TrackingVH<MDNode> instead of MDNode in AllRetainTypes, since the created
node can later be updated.
The change will be tested when clients of DIBuilder start to pass in non-empty
unique identifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189621 91177308-0d34-0410-b5e6-96231b3b80d8
In addition to recognizing when the multiply's second argument is
coming from an explicit VDUPLANE, also look for a plain scalar
f32 reference and reference it via the corresponding vector
lane.
rdar://14870054
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189619 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Made UnicodeCharSet a class, perform validity checking inside its
constructor instead of each isCharInSet call, use std::binary_search instead of
own implementation.
This patch comes with a necessary change in clang (sent separately).
Reviewers: jordan_rose, klimek
Reviewed By: klimek
CC: cfe-commits, rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1534
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189582 91177308-0d34-0410-b5e6-96231b3b80d8
Revert unintentional commit (of an unreviewed change).
Original commit message:
Add getUnrollingPreferences to TTI
Allow targets to customize the default behavior of the generic loop unrolling
transformation. This will be used by the PowerPC backend when targeting the A2
core (which is in-order with a deep pipeline), and using more aggressive
defaults is important.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189566 91177308-0d34-0410-b5e6-96231b3b80d8
Allow targets to customize the default behavior of the generic loop unrolling
transformation. This will be used by the PowerPC backend when targeting the A2
core (which is in-order with a deep pipeline), and using more aggressive
defaults is important.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189565 91177308-0d34-0410-b5e6-96231b3b80d8
This uses the TargetSubtargetInfo::useAA() function to control the defaults of
the -combiner-alias-analysis and -combiner-global-alias-analysis options.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189564 91177308-0d34-0410-b5e6-96231b3b80d8
There are several optional (off-by-default) features in CodeGen that can make
use of alias analysis. These features are important for generating code for
some kinds of cores (for example the (in-order) PPC A2 core). This adds a
useAA() function to TargetSubtargetInfo to allow these features to be enabled
by default on a per-subtarget basis.
Here is the first use of this function: To control the default of the
-enable-aa-sched-mi feature.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189563 91177308-0d34-0410-b5e6-96231b3b80d8
32-bit absolute addressing in instructions likei this:
mov $_f, %rsi
which is not supported in 64-bit mode.
rdar://8827134
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189543 91177308-0d34-0410-b5e6-96231b3b80d8
1. They are a kind of cannonicalization.
2. The performance measurements show that it is better to keep them in.
There should be no functional change if you are not enabling the LateVectorization mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189539 91177308-0d34-0410-b5e6-96231b3b80d8
When unrolling is disabled in the pass manager, the loop vectorizer should also
not unroll loops. This will allow the -fno-unroll-loops option in Clang to
behave as expected (even for vectorizable loops). The loop vectorizer's
-force-vector-unroll option will (continue to) override the pass-manager
setting (including -force-vector-unroll=0 to force use of the internal
auto-selection logic).
In order to test this, I added a flag to opt (-disable-loop-unrolling) to force
disable unrolling through opt (the analog of -fno-unroll-loops in Clang). Also,
this fixes a small bug in opt where the loop vectorizer was enabled only after
the pass manager populated the queue of passes (the global_alias.ll test needed
a slight update to the RUN line as a result of this fix).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189499 91177308-0d34-0410-b5e6-96231b3b80d8
with a debug build) with this buggy .indirect_symbol directive usage:
% cat test.s
x: .indirect_symbol _y
The assertion is because it is trying to get the symbol index for the
symbol _y when it is writing out the indirect symbol table. This line of
code in MachObjectWriter::WriteObject() :
Write32(Asm.getSymbolData(*it->Symbol).getIndex());
And while there is a symbol _y it does not have any getSymbolData set which
is only done in MachObjectWriter::BindIndirectSymbols() for pointer sections
or stub sections. I added a check and an error in there to catch this in case
something slips through.
But to get a better error the parser should detect when a .indirect_symbol
directive is used and it is not in a pointer section or stub section. To make
that work I moved the handling of the indirect symbol out of the target
independent AsmParser code into the DarwinAsmParser code that can check
for the proper Mach-O section types.
rdar://14825505
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189497 91177308-0d34-0410-b5e6-96231b3b80d8
With the added debug assertions this fix is covered by existing Clang
tests. (& found some other issues, also fixed)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189495 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a few things in one swoop.
# Add some negative tests.
# Fix some formatting issues.
# Add some missing IsThumb / ARMv8
# Fix some outs / ins mistakes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189490 91177308-0d34-0410-b5e6-96231b3b80d8
The usual default of "dmb ish" (inner-shareable) isn't even a valid instruction
on v6M or v7M (well, it does the same thing but software is strongly
discouraged from using it) so we should emit a full-system barrier there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189483 91177308-0d34-0410-b5e6-96231b3b80d8
Clang is now generating cleaner IR, so this removes the old variants which
should be completely unused.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189481 91177308-0d34-0410-b5e6-96231b3b80d8
The vqdmlal and vqdmlls instructions are really just a fused pair consisting of
a vqdmull.sN and a vqadd.sN. This adds patterns to LLVM so that we can switch
Clang's CodeGen over to generating these instead of the special vqdmlal
intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189480 91177308-0d34-0410-b5e6-96231b3b80d8
These intrinsics are legalized to V(ALL|ANY)_(NON)?ZERO nodes,
are matched as SN?Z_[BHWDV]_PSEUDO pseudo's, and emitted as
a branch/mov sequence to evaluate to 0 or 1.
Note: The resulting code is sub-optimal since it doesnt seem to be possible
to feed the result of an intrinsic directly into a brcond. At the moment
it uses (SETCC (VALL_ZERO $ws), 0, SETEQ) and similar which unnecessarily
evaluates the boolean twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189478 91177308-0d34-0410-b5e6-96231b3b80d8
For now just handles simple comparisons of an ANDed value with zero.
The CC value provides enough information to do any comparison for a
2-bit mask, and some nonzero comparisons with more populated masks,
but that's all future work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189469 91177308-0d34-0410-b5e6-96231b3b80d8
The MSA control registers have been added as reserved registers,
and are only used via ISD::Copy(To|From)Reg. The intrinsics are lowered
into these nodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189468 91177308-0d34-0410-b5e6-96231b3b80d8
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189442 91177308-0d34-0410-b5e6-96231b3b80d8
The problem with having DefaultSlabAllocator being a global static is that it is undefined if BumpPtrAllocator
will be usable during global initialization because it is not guaranteed that DefaultSlabAllocator will be
initialized before BumpPtrAllocator is created and used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189433 91177308-0d34-0410-b5e6-96231b3b80d8
algorithm. Update the split dwarf hashing testcase accordingly - this
should be the last time that the hash of an empty file changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189427 91177308-0d34-0410-b5e6-96231b3b80d8
when we can. Migrate from using blocks when we're adding just a
single attribute and floating point values are an unsigned, not signed,
bag of bits.
Update all test cases accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189419 91177308-0d34-0410-b5e6-96231b3b80d8
Link.exe's command line options are case-insensitive. This patch
adds a new attribute to OptTable to let the option parser to compare
options, ignoring case.
Command lines are generally case-insensitive on Windows. CL.exe is an
exception. So this new attribute should be useful for other commands
running on Windows.
Differential Revision: http://llvm-reviews.chandlerc.com/D1485
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189416 91177308-0d34-0410-b5e6-96231b3b80d8
createClassType, createStructType, createUnionType, createEnumerationType,
and createForwardDecl will take an optional StringRef to pass in
the unique identifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189410 91177308-0d34-0410-b5e6-96231b3b80d8
first. Use this to turn the PPC modifiers into PPC specific expressions,
allowing them to work on constants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189400 91177308-0d34-0410-b5e6-96231b3b80d8
This patch merges LoopVectorize of InnerLoopVectorizer and InnerLoopUnroller by adding checks for VF=1. This helps in erasing the Unroller code that is almost identical to the InnerLoopVectorizer code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189391 91177308-0d34-0410-b5e6-96231b3b80d8
We want to convert code like (or (srl N, 8), (shl N, 8)) into (srl (bswap N),
const), but this is only valid if the bits above 16 on the source pattern are
0, the checks we were doing on this were slightly wrong before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189348 91177308-0d34-0410-b5e6-96231b3b80d8
These instructions aren't particularly complicated and it's well worth having
patterns for some reasonably useful LLVM IR that will match them. Soon we
should be able to switch Clang over to producing this natural version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189335 91177308-0d34-0410-b5e6-96231b3b80d8
Lengths up to a certain threshold (currently 6 * 256) use a series of MVCs.
Lengths above that threshold use a loop to handle X*256 bytes followed
by a single MVC to handle the excess (if any). This loop will also be
needed in future when support for variable lengths is added.
Because the same tablegen classes are used to define MVC and CLC,
the patch also has the side-effect of defining a pseudo loop instruction
for CLC. That instruction isn't used yet (and wouldn't be handled correctly
if it were). I'm planning to use it soon though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189331 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
1) Make llvm-symbolizer properly symbolize
files with split debug info (by using stanalone .dwo files).
2) Make DWARFCompileUnit parse and store corresponding .dwo file,
if necessary.
3) Make bits of DWARF parsing more CompileUnit-oriented.
Reviewers: echristo
Reviewed By: echristo
CC: bkramer, llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1164
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189329 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189321 91177308-0d34-0410-b5e6-96231b3b80d8
Right now we have two headers for the Mach-O format. I'd like to get rid
of one. Since the other object formats are all in Support, I chose to
keep the Mach-O header in Support, and discard the other one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189314 91177308-0d34-0410-b5e6-96231b3b80d8
The code offset for unwind code SET_FPREG is wrong because it is set
to constant 0. The fix is to do the same as for the other unwind
codes: emit a label and later the absolute difference between the
label and the begin of the prologue.
Also enables the failing test case MC/COFF/seh.s
Reviewed by Jim Grosbach, Charles Davis and Nico Rieck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189309 91177308-0d34-0410-b5e6-96231b3b80d8
is constructing from as an input and keep the same unique identifier.
We can use this to connect items which must stay in the .o file
(e.g. pubnames and pubtypes) to the skeleton cu rather than having
duplicate unique numbers for the sections and needing to do lookups
based on MDNode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189293 91177308-0d34-0410-b5e6-96231b3b80d8
it by default under linux or when we're trying to keep compatibility
with old gdb versions.
Fix testcase for option name change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189289 91177308-0d34-0410-b5e6-96231b3b80d8
The builder inserts from before the insert point,
not after, so this would insert before the last
instruction in the bundle instead of after it.
I'm not sure if this can actually be a problem
with any of the current insertions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189285 91177308-0d34-0410-b5e6-96231b3b80d8
DICompositeType will have an identifier field at position 14. For now, the
field is set to null in DIBuilder.
For DICompositeTypes where the template argument field (the 13th field)
was optional, modify DIBuilder to make sure the template argument field is set.
Now DICompositeType has 15 fields.
Update DIBuilder to use NULL instead of "i32 0" for null value of a MDNode.
Update verifier to check that DICompositeType has 15 fields and the last
field is null or a MDString.
Update testing cases to include an extra field for DICompositeType.
The identifier field will be used by type uniquing so a front end can
genearte a DICompositeType with a unique identifer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189282 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enables unrolling of loops when vectorization is legal but not profitable.
We add a new class InnerLoopUnroller, that extends InnerLoopVectorizer and replaces some of the vector-specific logic with scalars.
This patch does not introduce any runtime regressions and improves the following workloads:
SingleSource/Benchmarks/Shootout/matrix -22.64%
SingleSource/Benchmarks/Shootout-C++/matrix -13.06%
External/SPEC/CINT2006/464_h264ref/464_h264ref -3.99%
SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding -1.95%
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189281 91177308-0d34-0410-b5e6-96231b3b80d8
Get the register class right for the TST instruction. This keeps the
machine verifier happy, enabling us to turn it on for another test.
rdar://12594152
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189274 91177308-0d34-0410-b5e6-96231b3b80d8
Constant pool and global value reference instructions need more
restricted register classes than plain GPR.
rdar://12594152
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189270 91177308-0d34-0410-b5e6-96231b3b80d8
The create machine code wasn't properly in SSA, which the machine verifier
properly complains about. Now that fast-isel is closer to verifier clean,
errors like this show up more clearly.
Additionally, the Thumb pseudo tPICADD was used for both ARM and Thumb
mode functions, which is obviously wrong. Fix that along the way.
Test case is part of the following commit which will finish making an
additional fast-isel test verifier clean an enable it for the
regression test suite. This commit is separate since its not just
a verifier cleanup, but an actual correctness issue.
rdar://12594152 (for the fast-isel verifier aspects)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189269 91177308-0d34-0410-b5e6-96231b3b80d8
Incremental improvement to fast-isel for PPC64. This allows us to
select on ret, sext, and zext. Filling in sext/zext improves some of
the existing logic in handling compare-immediates that needed extends.
A simplified return convention for fast-isel is also added to the
PPC64 calling conventions. All call/return processing for DAG
selection is handled with custom code, so there isn't an existing CC
to rely on here. The include of PPCGenCallingConv.inc causes compiler
warnings due to the 32-bit calling conventions that are not used, so
the dummy function "usePPC32CCs()" is added here to silence those.
Test cases for the return and extend logic are added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189266 91177308-0d34-0410-b5e6-96231b3b80d8
If we have a binary operation like ISD:ADD, we can set the result type
equal to the result type of one of its operands rather than using
TargetLowering::getPointerTy().
Also, any use of DAG.getIntPtrConstant(C) as an operand for a binary
operation can be replaced with:
DAG.getConstant(C, OtherOperand.getValueType());
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189227 91177308-0d34-0410-b5e6-96231b3b80d8
This adds minimal support to the SelectionDAG for handling address spaces
with different pointer sizes. The SelectionDAG should now correctly
lower pointer function arguments to the correct size as well as generate
the correct code when lowering getelementptr.
This patch also updates the R600 DataLayout to use 32-bit pointers for
the local address space.
v2:
- Add more helper functions to TargetLoweringBase
- Use CHECK-LABEL for tests
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189221 91177308-0d34-0410-b5e6-96231b3b80d8
First chunk of actual fast-isel selection code. This handles direct
and indirect branches, as well as feeding compares for direct
branches. PPCFastISel::PPCEmitIntExt() is just roughed in and will be
expanded in a future patch. This also corrects a problem with
selection for constant pool entries in JIT mode or with small code
model.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189202 91177308-0d34-0410-b5e6-96231b3b80d8
-Assembly parser now properly check the size of the memory operation specified in intel syntax. So 'mov word ptr [5], al' is no longer accepted.
-x86-32 disassembly of these instructions no longer sign extends the 32-bit address immediate based on size.
-Intel syntax printing prints the ptr size and places brackets around the address immediate.
Known remaining issues with these instructions:
-Segment override prefix is not supported. PR16962 and PR16961.
-Immediate size should be changed by address size prefix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189201 91177308-0d34-0410-b5e6-96231b3b80d8
a non-constant GEP.
I don't have any test case that demonstrates this, Nadav (indirectly)
pointed this out in code review. I'm not sure how possible it is to
contrive a test case for the current users of this code that triggers
the bad issue sadly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189188 91177308-0d34-0410-b5e6-96231b3b80d8
We currently emit labels with the prefix Lllvm$workaround$fake$stub$ if
the target's MCAsmInfo has getLinkOnceDirective() mapped to something
interesting. This was apparently a work around introduced in r31033 for
binutils that we don't need anymore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189187 91177308-0d34-0410-b5e6-96231b3b80d8
I need to add the rest of these to the list or else to delay putting
out the actual stub until later in code generation when I know if
the external function ever got emitted
Resubmit this patch. The target triple needs to be added to the test so that
clang does not tell the backend the wrong target when the host is BSD. There
is a clang bug in here somewhere that I need to track down. At Mips this
has been filed internally as a bug.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189186 91177308-0d34-0410-b5e6-96231b3b80d8
I need to add the rest of these to the list or else to delay putting
out the actual stub until later in code generation when I know if
the external function ever got emitted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189161 91177308-0d34-0410-b5e6-96231b3b80d8
Estimate the cyclic critical path within a single block loop. If the
acyclic critical path is longer, then the loop will exhaust OOO
resources after some number of iterations. If lag between the acyclic
critical path and cyclic critical path is longer the the time it takes
to issue those loop iterations, then aggressively schedule for
latency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189120 91177308-0d34-0410-b5e6-96231b3b80d8
This will be used to compute the cyclic critical path and to
update precomputed per-node pressure differences.
In the longer term, it could also be used to speed up LiveInterval
update by avoiding visiting all global vreg users.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189118 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a pathological compile time problem with very large blocks
and lots of scheduling boundaries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189116 91177308-0d34-0410-b5e6-96231b3b80d8
The code was erroneously reading overflow area shadow from the TLS slot,
bypassing the local copy. Reading shadow directly from TLS is wrong, because
it can be overwritten by a nested vararg call, if that happens before va_start.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189104 91177308-0d34-0410-b5e6-96231b3b80d8
This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the
exception of interprocedural optimization passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189101 91177308-0d34-0410-b5e6-96231b3b80d8
If we had a store of an integer to memory, and the integer and store size
were suitable for a form of MV..., we used MV... no matter what. We could
then have sequences like:
lay %r2, 0(%r3,%r4)
mvi 0(%r2), 4
In these cases it seems better to force the constant into a register
and use a normal store:
lhi %r2, 4
stc %r2, 0(%r3, %r4)
since %r2 is more likely to be hoisted and is easier to rematerialize.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189098 91177308-0d34-0410-b5e6-96231b3b80d8
...so that it can be used for z too. Most of the code is the same.
The only real change is to use TargetTransformInfo to test when a sqrt
instruction is available.
The pass is opt-in because at the moment it only handles sqrt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189097 91177308-0d34-0410-b5e6-96231b3b80d8
I'd forgotten that "Requires" blocks override rather than add to the
constraints, so my pseudo-instruction was being selected in Thumb mode leading
to nonsense instructions.
rdar://problem/14817358
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189096 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is a part of D1164. DWARFCompileUnit is not that lightweight
to copy it around, and we want it to own corresponding .dwo compile unit
eventually.
Reviewers: echristo
Reviewed By: echristo
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1298
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189089 91177308-0d34-0410-b5e6-96231b3b80d8
This field specifies registers that are preserved across function calls,
but that should not be included in the generates SaveList array.
This can be used ot generate regmasks for architectures that save
registers through other means, like SPARC's register windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189084 91177308-0d34-0410-b5e6-96231b3b80d8
The current version of StripDeadDebugInfo became stale and no longer actually
worked since it was expecting an older version of debug info.
This patch updates it to use DebugInfoFinder and the modern DebugInfo classes as
much as possible to make it more redundent to such changes. Additionally, the
only place where that was avoided (the code where we replace the old sets with
the new), I call verify on the DIContextUnit implying that if the format changes
and my live set changes no longer make sense an assert will be hit. In order to
ensure that that occurs I have included a test case.
The actual stripping of the dead debug info follows the same strategy as was
used before in this class: find the live set and replace the old set in the
given compile unit (which may contain dead global variables/functions) with the
new live one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189078 91177308-0d34-0410-b5e6-96231b3b80d8
DFSan changes the ABI of each function in the module. This makes it possible
for a function with the native ABI to be called with the instrumented ABI,
or vice versa, thus possibly invoking undefined behavior. A simple way
of statically detecting instances of this problem is to prepend the prefix
"dfs$" to the name of each instrumented-ABI function.
This will not catch every such problem; in particular function pointers passed
across the instrumented-native barrier cannot be used on the other side.
These problems could potentially be caught dynamically.
Differential Revision: http://llvm-reviews.chandlerc.com/D1373
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189052 91177308-0d34-0410-b5e6-96231b3b80d8
This uses the ARMcmov pattern that Tim cleaned up in r188995.
Thanks to Simon Tatham for his floating point help!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189024 91177308-0d34-0410-b5e6-96231b3b80d8
The instruction to convert between floating point and fixed point representations
takes an immediate operand for the number of fractional bits of the fixed point
value. ARMARM specifies that when that number of bits is zero, the assembler
should encode floating point/integer conversion instructions.
This patch adds the necessary instruction aliases to achieve this behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189009 91177308-0d34-0410-b5e6-96231b3b80d8
using GEPs. Previously, it used a number of different heuristics for
analyzing the GEPs. Several of these were conservatively correct, but
failed to fall back to SCEV even when SCEV might have given a reasonable
answer. One was simply incorrect in how it was formulated.
There was good code already to recursively evaluate the constant offsets
in GEPs, look through pointer casts, etc. I gathered this into a form
code like the SLP code can use in a previous commit, which allows all of
this code to become quite simple.
There is some performance (compile time) concern here at first glance as
we're directly attempting to walk both pointers constant GEP chains.
However, a couple of thoughts:
1) The very common cases where there is a dynamic pointer, and a second
pointer at a constant offset (usually a stride) from it, this code
will actually not do any unnecessary work.
2) InstCombine and other passes work very hard to collapse constant
GEPs, so it will be rare that we iterate here for a long time.
That said, if there remain performance problems here, there are some
obvious things that can improve the situation immensely. Doing
a vectorizer-pass-wide memoizer for each individual layer of pointer
values, their base values, and the constant offset is likely to be able
to completely remove redundant work and strictly limit the scaling of
the work to scrape these GEPs. Since this optimization was not done on
the prior version (which would still benefit from it), I've not done it
here. But if folks have benchmarks that slow down it should be straight
forward for them to add.
I've added a test case, but I'm not really confident of the amount of
testing done for different access patterns, strides, and pointer
manipulation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189007 91177308-0d34-0410-b5e6-96231b3b80d8