| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 353759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Except for custom floating point types x86_fp80 and ppc_fp128,
expand Y = FNEG(X) to Y = X ^ sign mask to avoid library call.
Using bitwise operation can improve code size and performance.
Reviewers: efriedma
Reviewed By: efriedma
Subscribers: efriedma, kpn, arsenm, eli.friedman, javed.absar, rbar, johnrusso, simoncook, sabuasal, niosHD, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, asb, llvm-commits
Differential Revision: https://reviews.llvm.org/D57875
llvm-svn: 353757
|
|
|
|
| |
llvm-svn: 353754
|
|
|
|
| |
llvm-svn: 353750
|
|
|
|
|
|
| |
The API indicates that the MI is about to be erased rather than it has been erased.
llvm-svn: 353746
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes PR40587.
When a dbg.value instrinsic is emitted to the DAG
by using EmitFuncArgumentDbgValue the resulting
DBG_VALUE is hoisted to the beginning of the entry
block. I think the idea is to be able to locate
a formal argument already from the start of the
function.
However, EmitFuncArgumentDbgValue only checked that
the value that was used to describe a variable was
originating from a function parameter, not that the
variable itself actually was an argument to the
function. So when for example assigning a local
variable "local" the value from an argument "a",
the assocated DBG_VALUE instruction would be hoisted
to the beginning of the function, even if the scope
for "local" started somewhere else (or if "local"
was mapped to other values earlier in the function).
This patch adds some logic to EmitFuncArgumentDbgValue
to check that the variable being described actually
is an argument to the function. And that the dbg.value
being lowered already is in the entry block. Otherwise
we bail out, and the dbg.value will be handled as an
ordinary dbg.value (not as a "FuncArgumentDbgValue").
A tricky situation is when both the variable and
the value is related to function arguments, but not
neccessarily the same argument. We make sure that we
do not describe the same argument more than once as
a "FuncArgumentDbgValue". This solution works as long
as opt has injected a "first" dbg.value that corresponds
to the formal argument at the function entry.
Reviewers: jmorse, aprantl
Subscribers: jyknight, hiraditya, fedor.sergeev, dstenb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57702
llvm-svn: 353735
|
|
|
|
|
|
|
|
|
|
|
| |
This teaches the legalizer about G_FFLOOR, and lets us select G_FFLOOR in
AArch64.
It updates the existing floating point tests, and adds a select-floor.mir test.
Differential Revision: https://reviews.llvm.org/D57486
llvm-svn: 353722
|
|
|
|
|
|
|
|
|
| |
After the changes introduced in r353586, this instruction doesn't cause any
issues for any backend.
Original review: https://reviews.llvm.org/D57485
llvm-svn: 353720
|
|
|
|
| |
llvm-svn: 353719
|
|
|
|
| |
llvm-svn: 353710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`CallBase` class rather than `CallSite` wrappers.
I pushed this change down through most of the statepoint infrastructure,
completely removing the use of CallSite where I could reasonably do so.
I ended up making a couple of cut-points: generic call handling
(instcombine, TLI, SDAG). As soon as it hit truly generic handling with
users outside the immediate code, I simply transitioned into or out of
a `CallSite` to make this a reasonable sized chunk.
Differential Revision: https://reviews.llvm.org/D56122
llvm-svn: 353660
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have vector support for [US](ADD|SUB)O we no longer
need to scalarize when expanding [US](ADD|SUB)SAT.
This matches what the cost model already does.
Differential Revision: https://reviews.llvm.org/D57348
llvm-svn: 353651
|
|
|
|
|
|
| |
No change in default behaviour (AllowUndefs = false)
llvm-svn: 353646
|
|
|
|
|
|
|
|
| |
Now that we have SimplifyDemandedBits support for funnel shifts (rL353539), we need to simplify funnel shifts back to bitshifts in cases where either argument has been folded to undef/zero.
Differential Revision: https://reviews.llvm.org/D58009
llvm-svn: 353645
|
|
|
|
|
|
|
|
|
|
| |
SimplifySetCC still has much room for improvement, but this should
fix the remaining problem examples from:
https://bugs.llvm.org/show_bug.cgi?id=40657
The initial fix for this problem was rL353615.
llvm-svn: 353639
|
|
|
|
|
|
|
|
|
| |
There's effectively no difference for the cases with variables.
We just trade a sub for an add on those. But the case with a
subtract from constant would require an extra move instruction
on x86, so this looks like a reasonable generic combine.
llvm-svn: 353619
|
|
|
|
| |
llvm-svn: 353615
|
|
|
|
|
|
|
|
| |
This reverts commit r353611.
Triggers an assertion during the libcall expansion on ARM.
llvm-svn: 353612
|
|
|
|
|
|
|
|
|
| |
In preparation for supporting vector expansion.
Also drop a variant of ExpandLibCall, of which the MULO expansions
were the only user.
llvm-svn: 353611
|
|
|
|
|
|
|
|
| |
CSEMIRBuilder"
With a fix after r353563 that adds some more opcodes.
llvm-svn: 353579
|
|
|
|
|
|
|
|
|
|
|
|
| |
CSEMIRBuilder"
This reverts commit r353553.
This breaks CodeGen/AArch64/GlobalISel/legalize-ext-csedebug-output.mir:
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/57963/console
llvm-svn: 353575
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch accompanies the RFC posted here:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html
This patch adds a new CallBr IR instruction to support asm-goto
inline assembly like gcc as used by the linux kernel. This
instruction is both a call instruction and a terminator
instruction with multiple successors. Only inline assembly
usage is supported today.
This also adds a new INLINEASM_BR opcode to SelectionDAG and
MachineIR to represent an INLINEASM block that is also
considered a terminator instruction.
There will likely be more bug fixes and optimizations to follow
this, but we felt it had reached a point where we would like to
switch to an incremental development model.
Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii
Differential Revision: https://reviews.llvm.org/D53765
llvm-svn: 353563
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sqrt case is faster and we already do this for the case where
the exponent is 0.25. This adds the 0.75 case which is also not
sensitive to signed zeros.
Patch by Whitney Tsang (Whitney)
Differential revision: https://reviews.llvm.org/D57434
llvm-svn: 353557
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D57932
Add some logging + tests to make sure CSEInfo prints debug output.
reviewed by: arsenm
llvm-svn: 353553
|
|
|
|
|
|
| |
Replace OR(SHL,SRL) pattern with ISD::FSHR (legalization expands this later if necessary) - this helps with the scale == 0 'undefined' drop-through case that was discussed on D55720.
llvm-svn: 353546
|
|
|
|
| |
llvm-svn: 353539
|
|
|
|
|
|
|
|
| |
combine."
This cleanup causes out-of-tree crashes.
llvm-svn: 353527
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make behavior of G_LOAD in widenScalar same as for G_ZEXTLOAD and
G_SEXTLOAD. That is perform widenScalarDst to size given by the target
and avoid additional checks in common code. Targets can reorder or add
additional rules in LegalizeRuleSet for the opcode to achieve desired
behavior.
Select extending load that does not have specified type of extension
into zero extending load.
Select truncating store that stores number of bytes indicated by size
in MachineMemoperand.
Differential Revision: https://reviews.llvm.org/D57454
llvm-svn: 353520
|
|
|
|
|
|
|
| |
Use a placeholder constant for now on targets
that need the load from the queue ptr.
llvm-svn: 353497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of https://bugs.llvm.org/show_bug.cgi?id=40442.
Vector legalization is implemented for the add/sub overflow opcodes.
UMULO/SMULO are also handled as far as legalization is concerned, but
they don't support vector expansion yet (so no tests for them).
The vector result widening implementation is suboptimal, because it
could result in a legalization loop.
Differential Revision: https://reviews.llvm.org/D57639
llvm-svn: 353464
|
|
|
|
|
|
| |
Don't rely on order of evaluation of function arguments.
llvm-svn: 353460
|
|
|
|
|
|
|
|
|
|
| |
Move the (add (umax X, C), -C) --> (usubsat X, C) X86 combine into generic DAGCombiner
First of a number of saturated arithmetic folds that can be moved out of X86-specific code for PR40111.
Differential Revision: https://reviews.llvm.org/D57754
llvm-svn: 353457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is pretty much directly ported from SelectionDAG. Doesn't include
the shift by non-constant but known bits version, since there isn't a
globalisel version of computeKnownBits yet.
This shows a disadvantage of targets not specifically which type
should be used for the shift amount. If type 0 is legalized before
type 1, the operations on the shift amount type use the wider type
(which are also less likely to legalize). This can be avoided by
targets specifying legalization actions on type 1 earlier than for
type 0.
llvm-svn: 353455
|
|
|
|
|
|
| |
Causes ASAN use-after-poison errors.
llvm-svn: 353442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed that we are missing this canonicalization in IR:
rL352515
...and then realized that we don't get this right in SDAG either,
so this has to be fixed first regardless of what we choose to do in IR.
The existing fold was limited to scalars and using the wrong predicate
to guard the transform. We have a boolean contents TLI query that can
be used to decide which direction to fold.
This may eventually lead back to the problems/question in:
https://bugs.llvm.org/show_bug.cgi?id=40486
...but it makes no difference to that yet.
Differential Revision: https://reviews.llvm.org/D57401
llvm-svn: 353433
|
|
|
|
|
|
|
|
|
| |
Introduce a new function which handles instructions with multiple type
indices, but have the same number of vector elements.
Also legalize v2s16 shifts when applicable.
llvm-svn: 353432
|
|
|
|
|
|
|
| |
Mostly keep the existing functions on scalars, but add versions which
also operate based on the vector element size.
llvm-svn: 353430
|
|
|
|
| |
llvm-svn: 353428
|
|
|
|
| |
llvm-svn: 353426
|
|
|
|
| |
llvm-svn: 353416
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This code tries to handle the case where IBB is an EHPad, but there's an earlier check that uses PBB->hasEHPadSuccessor(). Where PBB is a predecessor of IBB. The hasEHPadSuccessor function would have visited IBB and seen that it was an EHPad and returned false. This would prevent us from reaching this code with IBB as an EHPad.
Looks like this code was originally added in rL37427 (ancient) and made dead in rL143001.
Reviewers: rnk, void, efriedma
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D57358
llvm-svn: 353375
|
|
|
|
|
|
|
|
| |
This comment is old. The code in question was removed in rL203174
Differential Revision: https://reviews.llvm.org/D57856
llvm-svn: 353352
|
|
|
|
| |
llvm-svn: 353338
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instructions in GlobalIsel
Reviewers: aditya_nandakumar, volkan
Reviewed By: aditya_nandakumar
Subscribers: rovka, kristof.beyls, volkan, Petar.Avramovic
Differential Revision: https://reviews.llvm.org/D57630
llvm-svn: 353336
|
|
|
|
|
|
|
|
|
|
| |
Don't repeat the function name in some doxygen
comments.
(Just a minor cleanup, while testing to push
from the git monorepo setup.)
llvm-svn: 353317
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a lot of repeated code wrt unary math intrinsics in
translateKnownIntrinsic. This factors out the repeated MIRBuilder code into
two functions: translateSimpleUnaryIntrinsic and getSimpleUnaryIntrinsicOpcode.
This simplifies adding simple unary intrinsics, since after this, all you have
to do is add the mapping to SimpleUnaryIntrinsicOpcodes.
Differential Revision: https://reviews.llvm.org/D57774
llvm-svn: 353316
|
|
|
|
|
|
|
| |
Allow custom handling of inline assembly output parameters and add X86
flag parameter support.
llvm-svn: 353307
|
|
|
|
| |
llvm-svn: 353305
|
|
|
|
|
|
|
| |
GatherAllAliases only makes sense for LSBaseSDNode. Enforce it with
static typing instead of runtime cast.
llvm-svn: 353291
|
|
|
|
| |
llvm-svn: 353209
|