If there was a tail call, we would incorrectly handle the relocation. It would
end up indexing into the array with an incorrect section id. The symbol was
external to the module, so the Section ID was UNDEFINED (-1). We would then
index the SmallVector with this ID, triggering an assertion. Use the Value
rather than the section load address in this case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275442 91177308-0d34-0410-b5e6-96231b3b80d8
Note: I removed the checks after each jump because that's noise, but we apparently
need branches rather than returning i1 to see the bt codegen in some cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275439 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
- Give it a shorter name (because we're going to refer to it often from
SelectionDAG and friends).
- Split the flags and alignment into separate variables.
- Specialize FlagsEnumTraits for it, so we can do bitwise ops on it
without losing type information.
- Make some enum values constants in MachineMemOperand instead.
MOMaxBits should not be a valid Flag.
- Simplify some of the bitwise ops for dealing with Flags.
Reviewers: chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D22281
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275438 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In preparation for changing GlobalsAA to stop assuming that intrinsics
can't read arbitrary globals, we need to make sure GlobalsAA is querying
function attributes rather than relying on this assumption.
This patch was inspired by: http://reviews.llvm.org/D20206
Reviewers: jmolloy, hfinkel
Subscribers: eli.friedman, llvm-commits
Differential Revision: https://reviews.llvm.org/D21318
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275433 91177308-0d34-0410-b5e6-96231b3b80d8
We were able to assemble, but not disassemble.
Note that fixupRMValue was truncating EA_REG_BND0-3 because we hit
the uint8_t max. The control registers were already squarely above
it, but I don't think they ever go in .r/m, only in .reg.
I also did notice an extra REX.W in our encoding, but I think that's
fine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275427 91177308-0d34-0410-b5e6-96231b3b80d8
Nothing in-tree can tell the difference, but it's incorrect: the
addressing mode registers aren't what's defined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275426 91177308-0d34-0410-b5e6-96231b3b80d8
This patch prevents increases in the number of instructions, pre-instcombine,
due to induction variable scalarization. An increase in instructions can lead
to an increase in the compile-time required to simplify the induction
variables. We now maintain a new map for scalarized induction variables to
prevent us from converting between the scalar and vector forms.
This patch should resolve compile-time regressions seen after r274627.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275419 91177308-0d34-0410-b5e6-96231b3b80d8
stdcall is callee-pop like thiscall, so the thiscall changes already did most
of the work for this. This change only opts stdcall in and adds tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275414 91177308-0d34-0410-b5e6-96231b3b80d8
This improves the situation discussed in D19228 where we were forcing VPERMPD/VPERMQ where VPERM2F128/VPERM2I128 would have been better.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275411 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It was recently discovered that, for Mips's SelectionDAGISel subclasses,
all optimization levels caused SelectionDAGISel to behave like -O2.
This change adds the necessary plumbing to initialize the optimization level.
Reviewers: andrew.w.kaylor
Subscribers: andrew.w.kaylor, sdardis, dean, llvm-commits, vradosavljevic, petarj, qcolombet, probinson, dsanders
Differential Revision: https://reviews.llvm.org/D14900
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275410 91177308-0d34-0410-b5e6-96231b3b80d8
Primarily this is to allow blend with zero instead of having to use vperm2f128, but we can use this in the future to deal with AVX512 cases where we need to keep the original element size to correctly fold masked operations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275406 91177308-0d34-0410-b5e6-96231b3b80d8
enables the code size optimisation to fold a rem and div into a single
aeabi_uidivmod call. This was not happening before because sdiv was converted
but srem not, and instructions with different signedness are not combined.
Differential Revision: http://reviews.llvm.org/D22214
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275403 91177308-0d34-0410-b5e6-96231b3b80d8
This pass hoists duplicated computations in the program. The primary goal of
gvn-hoist is to reduce the size of functions before inline heuristics to reduce
the total cost of function inlining.
Pass written by Sebastian Pop, Aditya Kumar, Xiaoyu Hu, and Brian Rzycki.
Important algorithmic contributions by Daniel Berlin under the form of reviews.
Differential Revision: http://reviews.llvm.org/D19338
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275401 91177308-0d34-0410-b5e6-96231b3b80d8
constant hoisting. It not only takes into account the number of uses and the
cost of expressions in which constants appear, but now also the resulting
integer range of the offsets. Thus, the algorithm maximizes the number of uses
within an integer range that will enable more efficient code generation. On
ARM, for example, this will enable code size optimisations because less
negative offsets will be created. Negative offsets/immediates are not supported
by Thumb1 thus preventing more compact instruction encoding.
Differential Revision: http://reviews.llvm.org/D21183
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275382 91177308-0d34-0410-b5e6-96231b3b80d8
We were able to fold masked loads with an all-ones mask to a normal
load. However, we couldn't turn a masked load with a mask with mixed
ones and undefs into a normal load.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275380 91177308-0d34-0410-b5e6-96231b3b80d8
We can always pick the passthru value if the mask is undef: we are
permitted to treat the mask as-if it were filled with zeros.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275379 91177308-0d34-0410-b5e6-96231b3b80d8
It wasn't actually running the pass, and since it is
missing the llvm prefix, the eh intrinsic was not
really an IntrinsicInst.
Also add missing test for lifetime markers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275370 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In this patch we implement the following parts of XRay:
- Supporting a function attribute named 'function-instrument' which currently only supports 'xray-always'. We should be able to use this attribute for other instrumentation approaches.
- Supporting a function attribute named 'xray-instruction-threshold' used to determine whether a function is instrumented with a minimum number of instructions (IR instruction counts).
- X86-specific nop sleds as described in the white paper.
- A machine function pass that adds the different instrumentation marker instructions at a very late stage.
- A way of identifying which return opcode is considered "normal" for each architecture.
There are some caveats here:
1) We don't handle PATCHABLE_RET in platforms other than x86_64 yet -- this means if IR used PATCHABLE_RET directly instead of a normal ret, instruction lowering for that platform might do the wrong thing. We think this should be handled at instruction selection time to by default be unpacked for platforms where XRay is not availble yet.
2) The generated section for X86 is different from what is described from the white paper for the sole reason that LLVM allows us to do this neatly. We're taking the opportunity to deviate from the white paper from this perspective to allow us to get richer information from the runtime library.
Reviewers: sanjoy, eugenis, kcc, pcc, echristo, rnk
Subscribers: niravd, majnemer, atrick, rnk, emaste, bmakam, mcrosier, mehdi_amini, llvm-commits
Differential Revision: http://reviews.llvm.org/D19904
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275367 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In Scalarizer::gather we see if we already have a scattered form of Op,
and in that case use the new form.
In the particular case of PR28108, the found ValueVector SV has size 2,
where the first Value is nullptr, and the second is indeed a proper Value.
The nullptr then caused an assert to blow when we tried to do
cast<Instruction>(SV[I]).
With this patch we check SV[I] before doing the cast, and if it's nullptr
we just skip over it.
I don't know the Scalarizer well enough to know if this is the best fix
or if something should be done else where to prevent the nullptr from
being in the ValueVector at all, but at least this avoids the crash
and looking at the test case output it looks reasonable.
Reviewers: hfinkel, frasercrmck, wala, mehdi_amini
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21518
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275359 91177308-0d34-0410-b5e6-96231b3b80d8
