[CodeGen] Omit range checks from jump tables when lowering switches with unreachable default

During the lowering of a switch that would result in the generation of a
jump table, a range check is per

[CodeGen] Omit range checks from jump tables when lowering switches with unreachable default

During the lowering of a switch that would result in the generation of a
jump table, a range check is performed before indexing into the jump
table, for the switch value being outside the jump table range and a
conditional branch is inserted to jump to the default block. In case the
default block is unreachable, this conditional jump can be omitted. This
patch implements omitting this conditional branch for unreachable
defaults.

Differential Revision: https://reviews.llvm.org/D52002
Reviewers: Hans Wennborg, Eli Freidman, Roman Lebedev

llvm-svn: 355490

show more ...

Reversing the commit of revision 355483 since it is giving a regression on a newly added test.

llvm-svn: 355487

[CodeGen] Omit range checks from jump tables when lowering switches with unreachable default

During the lowering of a switch that would result in the generation of a
jump table, a range check is per

[CodeGen] Omit range checks from jump tables when lowering switches with unreachable default

During the lowering of a switch that would result in the generation of a
jump table, a range check is performed before indexing into the jump
table, for the switch value being outside the jump table range and a
conditional branch is inserted to jump to the default block. In case the
default block is unreachable, this conditional jump can be omitted. This
patch implements omitting this conditional branch for unreachable
defaults.

Differential Revision: https://reviews.llvm.org/D52002
Reviewers: Hans Wennborg, Eli Freidman, Roman Lebedev

llvm-svn: 355483

show more ...

[WebAssembly] Delete ThrowUnwindDest map from WasmEHFuncInfo

Summary:
Before when we implemented the first EH proposal, 'catch <tag>'
instruction may not catch an exception so there were multiple EH

[WebAssembly] Delete ThrowUnwindDest map from WasmEHFuncInfo

Summary:
Before when we implemented the first EH proposal, 'catch <tag>'
instruction may not catch an exception so there were multiple EH pads an
exception can unwind to. That means a BB could have multiple EH pad
successors.

Now after we switched to the new proposal, every 'catch' instruction
catches an exception, and there is only one catchpad per catchswitch, so
we at most have one EH pad successor, making `ThrowUnwindDest` map in
`WasmEHInfo` unnecessary.

Keeping `ThrowUnwindDest` map in `WasmEHInfo` has its own problems,
because other optimization passes can split a BB that contains possibly
throwing calls (previously invokes), and we have to update the map every
time that happens, which is not easy for common CodeGen passes.

This also correctly updates successor info in LateEHPrepare when we add
a rethrow instruction.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58486

llvm-svn: 355296

show more ...

Seperate volatility and atomicity/ordering in SelectionDAG

At the moment, we mark every atomic memory access as being also volatile. This is unnecessarily conservative and prohibits many legal trans

Seperate volatility and atomicity/ordering in SelectionDAG

At the moment, we mark every atomic memory access as being also volatile. This is unnecessarily conservative and prohibits many legal transforms (DCE, folding, etc..).

This patch removes MOVolatile from the MachineMemOperands of atomic, but not volatile, instructions. This should be strictly NFC after a series of previous patches which have gone in to ensure backend code is conservative about handling of isAtomic MMOs. Once it's in and baked for a bit, we'll start working through removing unnecessary bailouts one by one. We applied this same strategy to the middle end a few years ago, with good success.

To make sure this patch itself is NFC, it is build on top of a series of other patches which adjust code to (for the moment) be as conservative for an atomic access as for a volatile access and build up a test corpus (mostly in test/CodeGen/X86/atomics-unordered.ll)..

Previously landed

D57593 Fix a bug in the definition of isUnordered on MachineMemOperand
D57596 [CodeGen] Be conservative about atomic accesses as for volatile
D57802 Be conservative about unordered accesses for the moment
rL353959: [Tests] First batch of cornercase tests for unordered atomics.
rL353966: [Tests] RMW folding tests w/unordered atomic operations.
rL353972: [Tests] More unordered atomic lowering tests.
rL353989: [SelectionDAG] Inline a single use helper function, and remove last non-MMO interface
rL354740: [Hexagon, SystemZ] Be super conservative about atomics
rL354800: [Lanai] Be super conservative about atomics
rL354845: [ARM] Be super conservative about atomics

Attention Out of Tree Backend Owners: This patch may break you. If it does, you can use the TLI getMMOFlags hook to restore the MOVolatile to any instruction you need to. (See llvm-dev thread titled "PSA: Changes to how atomics are handled in backends" started Feb 27, 2019.)

Differential Revision: https://reviews.llvm.org/D57601

llvm-svn: 355025

show more ...

DAG: Add helper for creating shifts with correct type

llvm-svn: 354649

Re-land part of r354244 "[DAGCombiner] Eliminate dead stores to stack."

This part introduces the lifetime node.

llvm-svn: 354578

Revert r354244 "[DAGCombiner] Eliminate dead stores to stack."

Breaks some bots.

llvm-svn: 354245

[DAGCombiner] Eliminate dead stores to stack.

Summary:
A store to an object whose lifetime is about to end can be removed.

See PR40550 for motivation.

Reviewers: niravd

Subscribers: llvm-commits

[DAGCombiner] Eliminate dead stores to stack.

Summary:
A store to an object whose lifetime is about to end can be removed.

See PR40550 for motivation.

Reviewers: niravd

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D57541

llvm-svn: 354244

show more ...

[X86] Fix LowerAsmOutputForConstraint.

Summary:
Update Flag when generating cc output.

Fixes PR40737.

Reviewers: rnk, nickdesaulniers, craig.topper, spatel

Subscribers: hiraditya, llvm-commits

T

[X86] Fix LowerAsmOutputForConstraint.

Summary:
Update Flag when generating cc output.

Fixes PR40737.

Reviewers: rnk, nickdesaulniers, craig.topper, spatel

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58283

llvm-svn: 354163

show more ...

Fix an accidentally flipped pair of arguments, NFCI

While rebasing a refactor in r353950 I accidentally swapped two function
arguments; one is SelectionDAGBuilders "current" DebugLoc, the other is t

Fix an accidentally flipped pair of arguments, NFCI

While rebasing a refactor in r353950 I accidentally swapped two function
arguments; one is SelectionDAGBuilders "current" DebugLoc, the other is the one
from the "current" debug intrinsic. They're probably always identical, but I
haven't proved that yet.

llvm-svn: 354019

show more ...

[SelectionDAG] Inline a single use helper function, and remove last non-MMO interface [NFC]

For D57601, we need to know whether the instruction is volatile. We'd either have to pass yet another par

[SelectionDAG] Inline a single use helper function, and remove last non-MMO interface [NFC]

For D57601, we need to know whether the instruction is volatile. We'd either have to pass yet another parameter, or just standardize on the MMO interface. I chose the second.

llvm-svn: 353989

show more ...

[SelectionDAG] Kill last uses of getAtomic w/o a MMO operand [NFC]

The helper function was used by only two callers, and largely ended up providing distinct functionality based on optional arguments

[SelectionDAG] Kill last uses of getAtomic w/o a MMO operand [NFC]

The helper function was used by only two callers, and largely ended up providing distinct functionality based on optional arguments and opcode. Inline and simply to make the functionality much more clear.

llvm-svn: 353977

show more ...

[DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEs

In this patch SelectionDAG tries to salvage any dbg.values that are going to be
dropped, in case they can be recovered fr

[DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEs

In this patch SelectionDAG tries to salvage any dbg.values that are going to be
dropped, in case they can be recovered from Values in the current BB. It also
strengthens SelectionDAGs handling of dangling debug data, so that dbg.values
are *always* emitted (as Undef or otherwise) instead of dangling forever.

The motivation behind this patch exists in the new test case: a memory address
(here a bitcast and GEP) exist in one basic block, and a dbg.value referring to
the address is left in the 'next' block. The base pointer is live across all
basic blocks. In current llvm trunk the dbg.value cannot be encoded, and it
isn't even emitted as an Undef DBG_VALUE.

The change is simply: if we're definitely going to drop a dbg.value, repeatedly
apply salvageDebugInfo to its operand until either we find something that can
be encoded, or we can't salvage any further in which case we produce an Undef
DBG_VALUE. To know when we're "definitely going to drop a dbg.value",
SelectionDAG signals SelectionDAGBuilder when all IR instructions have been
encoded to force salvaging. This ensures that any dbg.value that's dangling
after DAG creation will have a corresponding DBG_VALUE encoded.

Differential Revision: https://reviews.llvm.org/D57694

llvm-svn: 353954

show more ...

[DebugInfo][DAG] Refactor dbg.value lowering into its own method

This is a pure copy-and-paste job, moving the logic for lowering dbg.value
intrinsics to SDDbgValues into its own function. This is a

[DebugInfo][DAG] Refactor dbg.value lowering into its own method

This is a pure copy-and-paste job, moving the logic for lowering dbg.value
intrinsics to SDDbgValues into its own function. This is ahead of adding some
more users of this logic.

Differential Revision: https://reviews.llvm.org/D57697

llvm-svn: 353950

show more ...

[DebugInfo][DAG] Limit special-casing of dbg.values for Arguments

SelectionDAGBuilder has special handling for dbg.value intrinsics that are
understood to define the location of function parameters

[DebugInfo][DAG] Limit special-casing of dbg.values for Arguments

SelectionDAGBuilder has special handling for dbg.value intrinsics that are
understood to define the location of function parameters on entry to the
function. To enable this, we avoid recording a dbg.value as a virtual register
reference if it might be such a parameter, so that it later hits
EmitFuncArgumentDbgValue.

This patch reduces the set of circumstances where we avoid recording a
dbg.value as a virtual register reference, to allow more "normal" variables
to be recorded that way. We now only bypass for potential parameters if:
* The dbg.value operand is an Argument,
* The Variable is a parameter, and
* The Variable is not inlined.
meaning it's very likely that the dbg.value is a function-entry parameter
location.

Differential Revision: https://reviews.llvm.org/D57584

llvm-svn: 353948

show more ...

[SelectionDAGBuilder] Add restrictions to EmitFuncArgumentDbgValue

Summary:
This patch fixes PR40587.

When a dbg.value instrinsic is emitted to the DAG
by using EmitFuncArgumentDbgValue the resulti

[SelectionDAGBuilder] Add restrictions to EmitFuncArgumentDbgValue

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

show more ...

[CallSite removal] Migrate the statepoint GC infrastructure to use the
`CallBase` class rather than `CallSite` wrappers.

I pushed this change down through most of the statepoint infrastructure,
comp

[CallSite removal] Migrate the statepoint GC infrastructure to use the
`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

show more ...

Implementation of asm-goto support in LLVM

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

Implementation of asm-goto support in LLVM

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

show more ...

[CodeGen] Handle vector UADDO, SADDO, USUBO, SSUBO

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

[CodeGen] Handle vector UADDO, SADDO, USUBO, SSUBO

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

show more ...

[InlineAsm][X86] Add backend support for X86 flag output parameters.

Allow custom handling of inline assembly output parameters and add X86
flag parameter support.

llvm-svn: 353307

[SelectionDAGBuilder] Refactor Inline Asm output check. NFCI.

llvm-svn: 353305

[Intrinsic] Unsigned Fixed Point Multiplication Intrinsic

Add an intrinsic that takes 2 unsigned integers with the scale of them
provided as the third argument and performs fixed point multiplicatio

[Intrinsic] Unsigned Fixed Point Multiplication Intrinsic

Add an intrinsic that takes 2 unsigned integers with the scale of them
provided as the third argument and performs fixed point multiplication on
them.

This is a part of implementing fixed point arithmetic in clang where some of
the more complex operations will be implemented as intrinsics.

Differential Revision: https://reviews.llvm.org/D55625

llvm-svn: 353059

show more ...

[COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects

Summary: This fixes using the correct stack registers for SEH when stack realignment is needed or when variable s

[COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects

Summary: This fixes using the correct stack registers for SEH when stack realignment is needed or when variable size objects are present.

Reviewers: rnk, efriedma, ssijaric, TomTan

Reviewed By: rnk, efriedma

Subscribers: javed.absar, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D57183

llvm-svn: 352923

show more ...

[opaque pointer types] Pass function types to CallInst creation.

This cleans up all CallInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-ty

[opaque pointer types] Pass function types to CallInst creation.

This cleans up all CallInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-type.

Differential Revision: https://reviews.llvm.org/D57170

llvm-svn: 352909

show more ...