#
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
|