Currently, we create a G_CONSTANT for every "synthetic" integer
constant operand (for instance, for the G_GEP offset).
Instead, share the G_CONSTANTs we might have created by going through
the ValueToVReg machinery.
When we're emitting synthetic constants, we do need to get Constants from
the context. One could argue that we shouldn't modify the context at
all (for instance, this means that we're going to use a tad more memory
if the constant wasn't used elsewhere), but constants are mostly
harmless. We currently do this for extractvalue and all.
For constant fcmp, this does mean we'll emit an extra COPY, which is not
necessarily more optimal than an extra materialized constant.
But that preserves the current intended design of uniqued G_CONSTANTs,
and the rematerialization problem exists elsewhere and should be
resolved with a single coherent solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297875 91177308-0d34-0410-b5e6-96231b3b80d8
computeKnownBits didn't handle fp_to_fp16 to report
the high bits as 0. ARM maps the generic node to an instruction
that does not modify the high bits of the register, so introduce
a target node where the high bits are known 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297873 91177308-0d34-0410-b5e6-96231b3b80d8
If we got unlucky with register allocation and actual constpool placement, we
could end up producing a tTBB_JT with an index that's already been clobbered.
Technically, we might be able to fix this situation up with a MOV, but I think
the constant islands pass is complex enough without having to deal with more
weird edge-cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297871 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we preserve the IR layout, we would end up with all the newly
synthesized switch comparison blocks at the end of the function.
Instead, use a hopefully more reasonable layout, with the comparison
blocks immediately following the switch comparison blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297869 91177308-0d34-0410-b5e6-96231b3b80d8
It makes the output function layout more predictable; the layout has
an effect on performance, we don't want it to be at the mercy of the
translator's visitation order and such.
The predictable output is also easier to digest.
getOrCreateBB isn't appropriately named anymore, as it never needs to
create anything. Rename it and extract the MBB creation logic out of it.
A couple tests were sensitive to the order. Update them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297868 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, if you attempted to write a key/value pair and the
value was equal to the key's default value, we would not output
the value. Sometimes it is useful to be able to see this value
in the output anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297864 91177308-0d34-0410-b5e6-96231b3b80d8
These are not valid values of the enum, so this will improve clang
-Wcovered-switch-default diagnostics. It also fixes some
-Wbitfield-enum-conversion warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297863 91177308-0d34-0410-b5e6-96231b3b80d8
This patch replaces ORs with getHighBits/getLowBits etc. with setLowBits/setHighBits/setBitsFrom.
In a few of the places we weren't ORing, but the KnownZero/KnownOne vectors were already initialized to zero. We exploit this in most places already there were just some that were inconsistent.
Differential Revision: https://reviews.llvm.org/D30965
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297860 91177308-0d34-0410-b5e6-96231b3b80d8
The test has grown enough to be annoying to navigate.
While there, Remove unnecessary RUNs, and cleanup a couple comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297856 91177308-0d34-0410-b5e6-96231b3b80d8
Using the module ID here is wrong for a couple of reasons:
1) The module ID is not persisted, so we can end up with different
object file contents given the same input file (for example if the same
file is accessed via different paths).
2) With ThinLTO the module ID field may contain the path to a bitcode file,
which is incorrect, as the .file argument is supposed to contain the path to
a source file.
Differential Revision: https://reviews.llvm.org/D30584
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297853 91177308-0d34-0410-b5e6-96231b3b80d8
Reduced from a mixture of PR32273 and David Green's test cases showing SelectionDAG::ComputeNumSignBits not correctly handling BUILD_VECTOR implicit truncation of inputs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297847 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for recognizing more patterns to match to DEXT and
CINS instructions.
It finds cases where multiple instructions could be replaced with a single
DEXT or CINS instruction.
For example, for the following:
define i64 @dext_and32(i64 zeroext %a) {
entry:
%and = and i64 %a, 4294967295
ret i64 %and
}
instead of generating:
0000000000000088 <dext_and32>:
88: 64010001 daddiu at,zero,1
8c: 0001083c dsll32 at,at,0x0
90: 6421ffff daddiu at,at,-1
94: 03e00008 jr ra
98: 00811024 and v0,a0,at
9c: 00000000 nop
the following gets generated:
0000000000000068 <dext_and32>:
68: 03e00008 jr ra
6c: 7c82f803 dext v0,a0,0x0,0x20
Cases that are covered:
DEXT:
1. and $src, mask where mask > 0xffff
2. zext $src zero extend from i32 to i64
CINS:
1. and (shl $src, pos), mask
2. shl (and $src, mask), pos
3. zext (shl $src, pos) zero extend from i32 to i64
Patch by Violeta Vukobrat.
Differential Revision: https://reviews.llvm.org/D30464
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297832 91177308-0d34-0410-b5e6-96231b3b80d8
Different MCInstrAnalysis classes for arm and thumb mode, each with
their own evaluateBranch implementation. I added a test case and
fixed the coff-relocations test to use '<label>:' rather than
'<label>' in the CHECK-LABEL entries, since the ones without the
colon would match branch targets. Might be worth noticing that
llvm-objdump does not lookup the relocation and thus assigns it a
target depending on the encoded immediate which #0, so it thinks it
branches to the next instruction.
Committed on behalf of Andre Vieira (avieira).
Differential Revision: https://reviews.llvm.org/D30943
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297821 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, ParseCommandLineOptions returns false and ignores error messages
when IgnoreErrors. It would be useful to also return error messages if users
decide to check parsing result instead of having the program exit on error.
Reviewers: chandlerc, mehdi_amini, rnk
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30893
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297810 91177308-0d34-0410-b5e6-96231b3b80d8
Enable the selection of the 64-bit signed multiply accumulate
instructions which operate on 16-bit operands. These are enabled for
ARMv5TE onwards for ARM and for V6T2 and other DSP enabled Thumb
architectures.
Differential Revision: https://reviews.llvm.org/D30044
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297809 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: D25742 improved the precision of debug locations for PGO by removing debug locations from common tail when tail-merging. However, if identical insturctions that are merged into a common tail have the same debug locations, there's no need to remove them. This patch creates a merged debug location of identical instructions across SameTails and assign it to the instruction in the common tail, so that the debug locations are maintained if they are same across identical instructions.
Reviewers: aprantl, probinson, MatzeB, rob.lougher
Reviewed By: aprantl
Subscribers: andreadb, llvm-commits
Differential Revision: https://reviews.llvm.org/D30226
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297805 91177308-0d34-0410-b5e6-96231b3b80d8
On MachO platforms that use subsections-via-symbols dead code stripping will
drop prefix data. Unfortunately there is no great way to convey the relationship
between a function and its prefix data to the linker. We are forced to use a bit
of a hack: we give the prefix data it’s own symbol, and mark the actual function
entry an .alt_entry.
Patch by Moritz Angermann!
Differential Revision: https://reviews.llvm.org/D30770
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297804 91177308-0d34-0410-b5e6-96231b3b80d8
