| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 307243
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 307149
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 306875
|
|
|
|
|
|
|
| |
This is the dual problem to legalizing G_INSERTs so most of the code and
testing was cribbed from there.
llvm-svn: 306328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 305459
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 305340
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 301163
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, ab, qcolombet, aditya_nandakumar, rovka, kristof.beyls
Reviewed By: kristof.beyls
Subscribers: dberris, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D31750
llvm-svn: 300847
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 299931
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 299802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: [GlobalISel] implement narrowing for G_CONSTANT.
Reviewers: bogner, zvi, t.p.northover
Reviewed By: t.p.northover
Subscribers: llvm-commits, dberris, rovka, kristof.beyls
Differential Revision: https://reviews.llvm.org/D31744
llvm-svn: 299772
|
|
|
|
|
|
|
| |
The world isn't just x86 & ARM, some targets need to store -1 into the byte
when legalizing a bool store.
llvm-svn: 298453
|
|
|
|
|
|
|
| |
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.
llvm-svn: 298439
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 298254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 297512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 297491
|
|
|
|
|
|
|
| |
Amongst other things (I expect) this is necessary to ensure decent backtraces
when an "unreachable" is involved.
llvm-svn: 297413
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: rL297171 introduced G_FNEG for floating-point negation instruction and IRTranslator started to translate `FSUB -0.0, X` to `FNEG X`. This patch adds a default action for G_FNEG to avoid breaking existing targets.
Reviewers: qcolombet, ab, kristof.beyls, t.p.northover, aditya_nandakumar, dsanders
Reviewed By: qcolombet
Subscribers: dberris, rovka, llvm-commits
Differential Revision: https://reviews.llvm.org/D30721
llvm-svn: 297301
|
|
|
|
|
|
|
|
| |
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".
llvm-svn: 297226
|
|
|
|
|
|
|
| |
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.
llvm-svn: 297100
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 297042
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 296921
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 295255
|
|
|
|
|
|
| |
There's no instruction to implement it.
llvm-svn: 294531
|
|
|
|
|
|
|
|
| |
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[].
llvm-svn: 294519
|
|
|
|
|
|
| |
Otherwise there aren't any patterns to select them.
llvm-svn: 294261
|
|
|
|
|
|
|
| |
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.
llvm-svn: 294247
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 292828
|
|
|
|
|
|
|
| |
It's incorrect to ignore the higher bits of the integer source.
Teach the legalizer how to widen it.
llvm-svn: 292563
|
|
|
|
|
|
|
| |
The logic in r292461 is conservatively correct, but we should revisit
this later. Add a TODO so we don't forget.
llvm-svn: 292553
|
|
|
|
| |
llvm-svn: 292476
|
|
|
|
| |
llvm-svn: 292461
|
|
|
|
|
|
|
| |
Legalize stores of types that are too wide by breaking them up into
sequences of smaller stores.
llvm-svn: 292412
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 288712
|
|
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.
llvm-svn: 284287
|