History log of /llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (Results 1051 – 1075 of 2094)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# c018efd6 17-Jan-2017 Ahmed Bougacha <ahmed.bougacha@gmail.com>

[TLI] Robustize SDAG proto checking by merging it into TLI.

SelectionDAGBuilder recognizes libfuncs using some homegrown
parameter type-checking.

Use TLI instead, removing another heap of redundant

[TLI] Robustize SDAG proto checking by merging it into TLI.

SelectionDAGBuilder recognizes libfuncs using some homegrown
parameter type-checking.

Use TLI instead, removing another heap of redundant code.

This isn't strictly NFC, as the SDAG code was too lax.
Concretely, this means changes are required to two tests:
- calling a non-variadic function via a variadic prototype isn't OK;
it just happens to work on x86_64 (but not on, e.g., aarch64).
- mempcpy has a size_t parameter; the SDAG code accepts any integer
type, which meant using i32 on x86_64 worked.

I don't think it's worth supporting either of these (IMO) broken
testcases. Instead, fix them to be more correct.

llvm-svn: 292189

show more ...


# 061f4a5f 13-Jan-2017 Benjamin Kramer <benny.kra@googlemail.com>

Apply clang-tidy's performance-unnecessary-value-param to LLVM.

With some minor manual fixes for using function_ref instead of
std::function. No functional change intended.

llvm-svn: 291904


# 116bbab4 13-Jan-2017 Diana Picus <diana.picus@linaro.org>

[CodeGen] Rename MachineInstrBuilder::addOperand. NFC

Rename from addOperand to just add, to match the other method that has been
added to MachineInstrBuilder for adding more than just 1 operand.

S

[CodeGen] Rename MachineInstrBuilder::addOperand. NFC

Rename from addOperand to just add, to match the other method that has been
added to MachineInstrBuilder for adding more than just 1 operand.

See https://reviews.llvm.org/D28057 for the whole discussion.

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

llvm-svn: 291891

show more ...


# def496c0 10-Jan-2017 Matt Arsenault <Matthew.Arsenault@amd.com>

Remove unused CONVERT_RNDSAT intrinsics

llvm-svn: 291607


# 9e04befb 06-Jan-2017 David Majnemer <david.majnemer@gmail.com>

[SelectionDAG] Rework lowerRangeToAssertZExt

Utilize ConstantRange to make it easier to interpret range metadata.

llvm-svn: 291211


# eaba06cf 06-Jan-2017 David Majnemer <david.majnemer@gmail.com>

[SelectionDAG] Correctly transform range metadata to AssertZExt

We used the logBase2 of the high instead of the ceilLogBase2 resulting
in the wrong result for certain values. For example, it result

[SelectionDAG] Correctly transform range metadata to AssertZExt

We used the logBase2 of the high instead of the ceilLogBase2 resulting
in the wrong result for certain values. For example, it resulted in an
i1 AssertZExt when the exclusive portion of the range was 3.

llvm-svn: 291196

show more ...


# 4f31e52f 29-Dec-2016 Igor Laevsky <igmyrj@gmail.com>

Introduce element-wise atomic memcpy intrinsic

This change adds a new intrinsic which is intended to provide memcpy functionality
with additional atomicity guarantees. Please refer to the review thr

Introduce element-wise atomic memcpy intrinsic

This change adds a new intrinsic which is intended to provide memcpy functionality
with additional atomicity guarantees. Please refer to the review thread
or language reference for further details.

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

llvm-svn: 290708

show more ...


# 3b951570 21-Dec-2016 Oren Ben Simhon <oren.ben.simhon@intel.com>

[X86] Vectorcall Calling Convention - Adding CodeGen Complete Support

The vectorcall calling convention specifies that arguments to functions are to be passed in registers, when possible.
vectorcall

[X86] Vectorcall Calling Convention - Adding CodeGen Complete Support

The vectorcall calling convention specifies that arguments to functions are to be passed in registers, when possible.
vectorcall uses more registers for arguments than fastcall or the default x64 calling convention use.
The vectorcall calling convention is only supported in native code on x86 and x64 processors that include Streaming SIMD Extensions 2 (SSE2) and above.

The current implementation does not handle Homogeneous Vector Aggregates (HVAs) correctly and this review attempts to fix it.
This aubmit also includes additional lit tests to cover better HVAs corner cases.

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

llvm-svn: 290240

show more ...


# 17c7f703 14-Dec-2016 Stephan Bergmann <sbergman@redhat.com>

Replace APFloatBase static fltSemantics data members with getter functions

At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirec

Replace APFloatBase static fltSemantics data members with getter functions

At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.

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

llvm-svn: 289647

show more ...


# b9eb99f5 09-Dec-2016 Simon Pilgrim <llvm-dev@redking.me.uk>

Use SelectionDAG.getSplatBuildVector helper. NFCI.

llvm-svn: 289220


# ab85225b 02-Dec-2016 Peter Collingbourne <peter@pcc.me.uk>

IR: Change the gep_type_iterator API to avoid always exposing the "current" type.

Instead, expose whether the current type is an array or a struct, if an array
what the upper bound is, and if a stru

IR: Change the gep_type_iterator API to avoid always exposing the "current" type.

Instead, expose whether the current type is an array or a struct, if an array
what the upper bound is, and if a struct the struct type itself. This is
in preparation for a later change which will make PointerType derive from
Type rather than SequentialType.

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

llvm-svn: 288458

show more ...


# d0ee66c2 01-Dec-2016 Matthias Braun <matze@braunis.de>

Move most EH from MachineModuleInfo to MachineFunction

Recommitting r288293 with some extra fixes for GlobalISel code.

Most of the exception handling members in MachineModuleInfo is actually
per fu

Move most EH from MachineModuleInfo to MachineFunction

Recommitting r288293 with some extra fixes for GlobalISel code.

Most of the exception handling members in MachineModuleInfo is actually
per function data (talks about the "current function") so it is better
to keep it at the function instead of the module.

This is a necessary step to have machine module passes work properly.

Also:
- Rename TidyLandingPads() to tidyLandingPads()
- Use doxygen member groups instead of "//===- EH ---"... so it is clear
where a group ends.
- I had to add an ugly const_cast at two places in the AsmPrinter
because the available MachineFunction pointers are const, but the code
wants to call tidyLandingPads() in between
(markFunctionEnd()/endFunction()).

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

llvm-svn: 288405

show more ...


# e70b7c3d 01-Dec-2016 Eric Christopher <echristo@gmail.com>

Temporarily Revert "Move most EH from MachineModuleInfo to MachineFunction"

This apprears to have broken the global isel bot:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-globalisel_buil

Temporarily Revert "Move most EH from MachineModuleInfo to MachineFunction"

This apprears to have broken the global isel bot:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-globalisel_build/5174/console

This reverts commit r288293.

llvm-svn: 288322

show more ...


# ed14cb06 30-Nov-2016 Matthias Braun <matze@braunis.de>

Move most EH from MachineModuleInfo to MachineFunction

Most of the exception handling members in MachineModuleInfo is actually
per function data (talks about the "current function") so it is better

Move most EH from MachineModuleInfo to MachineFunction

Most of the exception handling members in MachineModuleInfo is actually
per function data (talks about the "current function") so it is better
to keep it at the function instead of the module.

This is a necessary step to have machine module passes work properly.

Also:
- Rename TidyLandingPads() to tidyLandingPads()
- Use doxygen member groups instead of "//===- EH ---"... so it is clear
where a group ends.
- I had to add an ugly const_cast at two places in the AsmPrinter
because the available MachineFunction pointers are const, but the code
wants to call tidyLandingPads() in between
(markFunctionEnd()/endFunction()).

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

llvm-svn: 288293

show more ...


# b30d2aca 21-Nov-2016 Matt Arsenault <Matthew.Arsenault@amd.com>

DAG: Ignore call site attributes when emitting target intrinsic

A target intrinsic may be defined as possibly reading memory,
but the call site may have additional knowledge that it doesn't read
mem

DAG: Ignore call site attributes when emitting target intrinsic

A target intrinsic may be defined as possibly reading memory,
but the call site may have additional knowledge that it doesn't read
memory. The intrinsic lowering will expect the pessimistic
assumption of the intrinsic definition, so the chain should
still be used.

llvm-svn: 287593

show more ...


# bd6ce9a2 16-Nov-2016 Ahmed Bougacha <ahmed.bougacha@gmail.com>

[CodeGen] Pass references, not pointers, to MMI helpers. NFC.

While there, rename them to follow the coding style.

llvm-svn: 287169


# 857efb08 07-Nov-2016 Richard Smith <richard-llvm@metafoo.co.uk>

Add -O0 support for @llvm.invariant.group.barrier by discarding it if it gets to ISel.

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

llvm-svn: 286119


# caaceef4 03-Nov-2016 Elena Demikhovsky <elena.demikhovsky@intel.com>

Expandload and Compressstore intrinsics

2 new intrinsics covering AVX-512 compress/expand functionality.
This implementation includes syntax, DAG builder, operation lowering and tests.
Does not incl

Expandload and Compressstore intrinsics

2 new intrinsics covering AVX-512 compress/expand functionality.
This implementation includes syntax, DAG builder, operation lowering and tests.
Does not include: handling of illegal data types, codegen prepare pass and the cost model.

llvm-svn: 285876

show more ...


# 601f4cb9 25-Oct-2016 Evandro Menezes <e.menezes@samsung.com>

Switch lowering: improve partitioning of jump tables

When there's a tie between partitionings of jump tables, consider also cases
that result in no jump tables, but in one or a few cases. The motiv

Switch lowering: improve partitioning of jump tables

When there's a tie between partitionings of jump tables, consider also cases
that result in no jump tables, but in one or a few cases. The motivation is
that many contemporary processors typically perform case switches fairly
quickly.

Differential revision: https://reviews.llvm.org/D25212

llvm-svn: 285099

show more ...


# 8ea0246e 15-Oct-2016 Konstantin Zhuravlyov <kzhuravl_dev@outlook.com>

[MachineMemOperand] Move synchronization scope and atomic orderings from SDNode to MachineMemOperand, and remove redundant getAtomic* member functions from SelectionDAG.

Differential Revision: https

[MachineMemOperand] Move synchronization scope and atomic orderings from SDNode to MachineMemOperand, and remove redundant getAtomic* member functions from SelectionDAG.

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

llvm-svn: 284312

show more ...


# 795d7d63 12-Oct-2016 Albert Gutowski <agutowski@google.com>

Create llvm.addressofreturnaddress intrinsic

Summary: We need a new LLVM intrinsic to implement MS _AddressOfReturnAddress builtin on 64-bit Windows.

Reviewers: majnemer, rnk

Subscribers: llvm-com

Create llvm.addressofreturnaddress intrinsic

Summary: We need a new LLVM intrinsic to implement MS _AddressOfReturnAddress builtin on 64-bit Windows.

Reviewers: majnemer, rnk

Subscribers: llvm-commits

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

llvm-svn: 284061

show more ...


# 5b10aa1f 09-Oct-2016 Elena Demikhovsky <elena.demikhovsky@intel.com>

DAG: Setting Masked-Expand-Load as a variant of Masked-Load node

Masked-expand-load node represents load operation that loads a variable amount of elements from memory according to amount of "true"

DAG: Setting Masked-Expand-Load as a variant of Masked-Load node

Masked-expand-load node represents load operation that loads a variable amount of elements from memory according to amount of "true" bits in the mask and expands the loaded elements according to their position in the mask vector.
Right now, the node is used in intrinsics for VEXPAND* instructions.
The work is done towards implementation of masked.expandload and masked.compressstore intrinsics.

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

llvm-svn: 283694

show more ...


# 3f256581 07-Oct-2016 Arnold Schwaighofer <aschwaighofer@apple.com>

swifterror: Don't compute swifterror vregs during instruction selection

The code used llvm basic block predecessors to decided where to insert phi
nodes. Instruction selection can and will liberally

swifterror: Don't compute swifterror vregs during instruction selection

The code used llvm basic block predecessors to decided where to insert phi
nodes. Instruction selection can and will liberally insert new machine basic
block predecessors. There is not a guaranteed one-to-one mapping from pred.
llvm basic blocks and machine basic blocks.

Therefore the current approach does not work as it assumes we can mark
predecessor machine basic block as needing a copy, and needs to know the set of
all predecessor machine basic blocks to decide when to insert phis.

Instead of computing the swifterror vregs as we select instructions, propagate
them at the end of instruction selection when the MBB CFG is complete.

When an instruction needs a swifterror vreg and we don't know the value yet,
generate a new vreg and remember this "upward exposed" use, and reconcile this
at the end of instruction selection.

This will only happen if the target supports promoting swifterror parameters to
registers and the swifterror attribute is used.

rdar://28300923

llvm-svn: 283617

show more ...


# e45de8a5 26-Sep-2016 Evandro Menezes <e.menezes@samsung.com>

Add support to optionally limit the size of jump tables.

Many high-performance processors have a dedicated branch predictor for
indirect branches, commonly used with jump tables. As sophisticated a

Add support to optionally limit the size of jump tables.

Many high-performance processors have a dedicated branch predictor for
indirect branches, commonly used with jump tables. As sophisticated as such
branch predictors are, they tend to have well defined limits beyond which
their effectiveness is hampered or even nullified. One such limit is the
number of possible destinations for a given indirect branches that such
branch predictors can handle.

This patch considers a limit that a target may set to the number of
destination addresses in a jump table.

Patch by: Evandro Menezes <e.menezes@samsung.com>, Aditya Kumar
<aditya.k7@samsung.com>, Sebastian Pop <s.pop@samsung.com>.

Differential revision: https://reviews.llvm.org/D21940

llvm-svn: 282412

show more ...


# de2490d0 21-Sep-2016 Arnold Schwaighofer <aschwaighofer@apple.com>

Disable tail calls if there is an swifterror argument

ISel does not handle them correctly yet i.e we crash trying to emit tail call
code.

radar://28407842

llvm-svn: 282088


1...<<41424344454647484950>>...84