Since the lambda isn't escaped (via a std::function or similar) it's
fine/better to use default capture-by-ref to provide semantics similar
to language-level nested scopes (if/for/while/etc).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311782 91177308-0d34-0410-b5e6-96231b3b80d8
Treat widening G_SREM and G_UREM the same as G_SDIV and G_UDIV. This is
going to be used in the ARM backend (and that's when the test will come
too).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308278 91177308-0d34-0410-b5e6-96231b3b80d8
This covers both hard and soft float.
Hard float is easy, since it's just Legal.
Soft float is more involved, because there are several different ways to
handle it based on the predicate: one and ueq need not only one, but two
libcalls to get a result. Furthermore, we have large differences between
the values returned by the AEABI and GNU functions.
AEABI functions return a nice 1 or 0 representing true and respectively
false. GNU functions generally return a value that needs to be compared
against 0 (e.g. for ogt, the value returned by the libcall is > 0 for
true). We could introduce redundant comparisons for AEABI as well, but
they don't seem easy to remove afterwards, so we do different processing
based on whether or not the result really needs to be compared against
something (and just truncate if it doesn't).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307243 91177308-0d34-0410-b5e6-96231b3b80d8
We used to have a helper that replaced an instruction with a libcall.
That turns out to be too aggressive, since sometimes we need to replace
the instruction with at least two libcalls. Therefore, change our
existing helper to only create the libcall and leave the instruction
removal as a separate step. Also rename the helper accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307149 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like there are two target-independent but not GISel instructions that
need legalization, IMPLICIT_DEF and PHI. These are already anomalies since
their operands have important LLTs attached, so to make things more uniform it
seems like a good idea to add generic variants. Starting with G_IMPLICIT_DEF.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306875 91177308-0d34-0410-b5e6-96231b3b80d8
This is the dual problem to legalizing G_INSERTs so most of the code and
testing was cribbed from there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306328 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for modulo for targets that have hardware division and for
those that don't. When hardware division is not available, we have to
choose the correct libcall to use. This is generally straightforward,
except for AEABI.
The AEABI variant is trickier than the other libcalls because it
returns { quotient, remainder }, instead of just one value like the
other libcalls that we've seen so far. Therefore, we need to use custom
lowering for it. However, we don't want to have too much special code,
so we refactor the target-independent code in the legalizer by adding a
helper for replacing an instruction with a libcall. This helper is used
by the legalizer itself when dealing with simple calls, and also by the
custom ARM legalization for the more complicated AEABI divmod calls.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305459 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When legalizing G_LOAD/G_STORE using NarrowScalar, we should avoid emitting
%0 = G_CONSTANT ty 0
%1 = G_GEP %x, %0
since it's cheaper to not emit the redundant instructions than it is to fold them
away later.
Reviewers: qcolombet, t.p.northover, ab, rovka, aditya_nandakumar, kristof.beyls
Reviewed By: qcolombet
Subscribers: javed.absar, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D32746
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305340 91177308-0d34-0410-b5e6-96231b3b80d8
Treat them the same as the other binary operations that we have so far,
but on integers rather than floating point types. Extract the common
code into a helper.
This will be used in the ARM backend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301163 91177308-0d34-0410-b5e6-96231b3b80d8
Use the same handling in the generic legalizer code as for the other
libcalls (G_FREM, G_FPOW).
Enable it on ARM for float and double so we can test it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299931 91177308-0d34-0410-b5e6-96231b3b80d8
The original instruction might get legalized and erased and expanded
into intermediate instructions and the intermediate instructions might
fail legalization. This end up in reporting GISelFailure on the erased
instruction.
Instead report GISelFailure on the intermediate instruction which failed
legalization.
Reviewed by: ab
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299802 91177308-0d34-0410-b5e6-96231b3b80d8
The world isn't just x86 & ARM, some targets need to store -1 into the byte
when legalizing a bool store.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298453 91177308-0d34-0410-b5e6-96231b3b80d8
A bool is represented by a single byte, which the ARM ABI requires to be either
0 or 1. So we cannot use G_ANYEXT when legalizing the type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298439 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a parameter that lets us pass in the calling convention
of the call to CallLowering::lowerCall. This allows us to handle
situations where the calling convetion of the callee is different from
that of the caller.
Differential Revision: https://reviews.llvm.org/D31039
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298254 91177308-0d34-0410-b5e6-96231b3b80d8
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
