Summary: No test case as none of the in-tree targets with GlobalISel support has this condition.
Reviewers: qcolombet, aditya_nandakumar, dsanders, t.p.northover, ab
Reviewed By: qcolombet
Subscribers: dberris, rovka, kristof.beyls, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D30786
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297512 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We don’t actually use LegalizerInfo in Legalizer pass, it’s just passed
as an argument.
In order to check if an instruction is legal or not, we need to get LegalizerInfo
by calling `MI.getParent()->getParent()->getSubtarget().getLegalizerInfo()`.
Instead, make LegalizerInfo accessible in LegalizerHelper.
Reviewers: qcolombet, aditya_nandakumar, dsanders, ab, t.p.northover, kristof.beyls
Reviewed By: qcolombet
Subscribers: dberris, llvm-commits, rovka
Differential Revision: https://reviews.llvm.org/D30838
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297491 91177308-0d34-0410-b5e6-96231b3b80d8
Amongst other things (I expect) this is necessary to ensure decent backtraces
when an "unreachable" is involved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297413 91177308-0d34-0410-b5e6-96231b3b80d8
We were calculating incorrect extract/insert offsets by trying to be too
tricksy with min/max. It's clearer to just split the logic up into "register
starts before this segment" vs "after".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297226 91177308-0d34-0410-b5e6-96231b3b80d8
A bit more painful than G_INSERT because it was more widely used, but this
should simplify the handling of extract operations in most locations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297100 91177308-0d34-0410-b5e6-96231b3b80d8
Now that G_INSERT instructions can only insert one register, this code was
overly general. In another direction it didn't handle registers that crossed
split boundaries properly, which needed to be fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297042 91177308-0d34-0410-b5e6-96231b3b80d8
These are simplified variants of the current G_SEQUENCE and G_EXTRACT, which
assume the individual parts will be contiguous, homogeneous, and occupy the
entirity of the larger register. This makes reasoning about them much easer
since you only have to look at the first register being merged and the result
to know what the instruction is doing.
I intend to gradually replace all uses of the more complicated sequence/extract
with these (or single-element insert/extracts), and then remove the older
variants. For now we start with legalization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296921 91177308-0d34-0410-b5e6-96231b3b80d8
Uses a Custom implementation because the slot sizes being a multiple of the
pointer size isn't really universal, even for the architectures that do have a
simple "void *" va_list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295255 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64 has specific instructions to multiply two numbers at double the width
and produce the high part of the result. These can be used to implement LLVM's
mul.with.overflow instructions fairly simply. Helps with C++ operator new[].
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294519 91177308-0d34-0410-b5e6-96231b3b80d8
We don't handle all cases yet (see arm64-fallback.ll for an example), but this
is enough to cover most common C++ code so it's a good place to start.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294247 91177308-0d34-0410-b5e6-96231b3b80d8
Since we're now avoiding operations using narrow scalar integer types,
we have to legalize the integer side of the FP conversions.
This requires teaching the legalizer how to do that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292828 91177308-0d34-0410-b5e6-96231b3b80d8
The logic in r292461 is conservatively correct, but we should revisit
this later. Add a TODO so we don't forget.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292553 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it more similar to the floating-point constant, and also allows for
larger constants to be translated later. There's no real functional change in
this patch though, just syntax updates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288712 91177308-0d34-0410-b5e6-96231b3b80d8
The previous names were both misleading (the MachineLegalizer actually
contained the info tables) and inconsistent with the selector & translator (in
having a "Machine") prefix. This should make everything sensible again.
The only functional change is the name of a couple of command-line options.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284287 91177308-0d34-0410-b5e6-96231b3b80d8