with user specified count has been applied.
Summary:
Previously SetLoopAlreadyUnrolled() set the disable pragma only if
there was some loop metadata.
Now it set the pragma in all cases. This helps to prevent multiple
unroll when -unroll-count=N is given.
Reviewers: mzolotukhin
Differential Revision: http://reviews.llvm.org/D20765
From: Evgeny Stupachenko <evstupac@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272195 91177308-0d34-0410-b5e6-96231b3b80d8
It provides nothing over the default one but makes the class not
trivially copyable. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272186 91177308-0d34-0410-b5e6-96231b3b80d8
Again, the Microsoft linker does not like empty substreams.
We still emit an empty string table if CodeView is enabled, but that
doesn't cause problems because it always contains at least one null
byte.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272183 91177308-0d34-0410-b5e6-96231b3b80d8
This is NFC as far as externally visible behavior is concerned, but will
keep us from spinning in the worklist traversal algorithm unnecessarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272182 91177308-0d34-0410-b5e6-96231b3b80d8
Absence of may-unwind calls is not enough to guarantee that a
UB-generating use of an add-rec poison in the loop latch will actually
cause UB. We also need to guard against calls that terminate the thread
or infinite loop themselves.
This partially addresses PR28012.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272181 91177308-0d34-0410-b5e6-96231b3b80d8
The worklist algorithm introduced in rL271151 didn't check to see if the
direct users of the post-inc add recurrence propagates poison. This
change fixes the problem and makes the code structure more obvious.
Note for release managers: correctness wise, this bug wasn't a
regression introduced by rL271151 -- the behavior of SCEV around
post-inc add recurrences was strictly improved (in terms of correctness)
in rL271151.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272179 91177308-0d34-0410-b5e6-96231b3b80d8
When repairing with a copy, instead of accounting for the cost of that
copy and actually inserting it, we may be able to use an alternative
source for the register to repair and just use it.
Make sure this is documented, so that we consider that opportunity at
some point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272176 91177308-0d34-0410-b5e6-96231b3b80d8
r272064 apparently made them angry. This undoes some changes made in
r272064 (defaulting move ctors) to make them happy again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272173 91177308-0d34-0410-b5e6-96231b3b80d8
Teach AArch64RegisterBankInfo that G_OR can be mapped on either GPR or
FPR for 64-bit or 32-bit values.
Add test cases demonstrating how this information is used to coalesce a
computation on a single register bank.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272170 91177308-0d34-0410-b5e6-96231b3b80d8
Now, the target will be able to provide its how implementation to remap
an instruction. This open the way to crazier optimizations, but to
beginning with, we will be able to handle something else than the
default mapping.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272165 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we have an entity that hold the remap information the
rewritting should be easier to do.
No functional changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272164 91177308-0d34-0410-b5e6-96231b3b80d8
When the command line option is set, it overrides any thing that the
target may have set. The rationale is that we get what we asked for.
Options are respectively regbankselect-fast and regbankselect-greedy for
fast and greedy mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272158 91177308-0d34-0410-b5e6-96231b3b80d8
repairing.
Copies are easy because we repair only when there is a mismatch. For
non-copy repairing, i.e., cases that involves breaking down or gathering
up the value, one of the operand may not have a register bank yet. Thus,
derivate a cost from that, requires more work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272157 91177308-0d34-0410-b5e6-96231b3b80d8
The MSR instructions can write to the CPSR, but we did not model this
fact, so we could emit them in the middle of IT blocks, changing the
condition flags for later instructions in the block.
The tests use two calls to llvm.write_register.i32 because it is valid
to use these instructions at the end of an IT block, which if conversion
does do in some cases. With two calls, the first clobbers the flags, so
a branch has to be used to make the second one conditional.
Differential Revision: http://reviews.llvm.org/D21139
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272154 91177308-0d34-0410-b5e6-96231b3b80d8
The architecture enumeration is shared across ARM and AArch64. However, the
data is not. The code incorrectly would index into the array using the
architecture index which was offset by the ARMv7 architecture enumeration. We
do not have a marker for indicating the architectural family to which the
enumeration belongs so we cannot be clever about offsetting the index (at least
it is not immediately apparent to me). Instead, fall back to the tried-and-true
method of slowly iterating the array (its not a large array, so the impact of
this is not too high).
Because of the incorrect indexing, if we were lucky, we would crash, but usually
we would return an invalid StringRef. We did not have any tests for the AArch64
target parser previously;. Extend the previous tests I had added for ARM to
cover AArch64 for ensuring that we return expected StringRefs.
Take the opportunity to change some iterator types to references.
This work is needed to support parsing `.arch name` directives in the AArch64
target asm parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272145 91177308-0d34-0410-b5e6-96231b3b80d8
Also, switch to using functions from LiveIntervalAnalysis to update
live intervals, instead of performing the updates manually.
Re-committing r272045.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272135 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested by clang-tidy's performance-unnecessary-copy-initialization.
This can easily hit lifetime issues, so I audited every change and ran the
tests under asan, which came back clean.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272126 91177308-0d34-0410-b5e6-96231b3b80d8
The generic implementation stated that all copies were free, which is
unlikely. Now, only the copies within the same register bank are free.
We assume they will get coalesced.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272085 91177308-0d34-0410-b5e6-96231b3b80d8
The cost of a copy may be different based on how many bits we have to
copy around. E.g., a 8-bit copy may be different than a 32-bit copy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272084 91177308-0d34-0410-b5e6-96231b3b80d8
The MachineMemOperand parser lacked the code to handle %stack.X
references (%fixed-stack.X was working).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272082 91177308-0d34-0410-b5e6-96231b3b80d8
