summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
* [Support/Endian] Add support for endian-specific enumsPavel Labath2019-03-111-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Binary formats often include various enumerations or bitsets, but using endian-specific types for accessing them is tricky because they currently only support integral types. This is particularly true for scoped enums (enum class), as these are not implicitly convertible to integral types, and so one has to perform two casts just to read the enum value. This fixes that support by adding first-class support for enumeration types to endian-specific types. The support for them was already almost working -- all I needed to do was overload getSwappedBytes for enumeration types (which casts the enum to its underlying type and performs the conversion there). I also add some convenience template aliases to simplify declaring endian-specific enums. Reviewers: Bigcheese, zturner Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59141 llvm-svn: 355812
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-084-0/+181
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355685
* Rollback of rL355585.Mitch Phillips2019-03-074-174/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduces memory leak in FunctionTest.GetPointerAlignment that breaks sanitizer buildbots: ``` ================================================================= ==2453==ERROR: LeakSanitizer: detected memory leaks Direct leak of 128 byte(s) in 1 object(s) allocated from: #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105 #1 0x16936bc in llvm::User::operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/User.cpp:151:19 #2 0x7c3fe9 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:12 #3 0x7c3fe9 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136 #4 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #5 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #6 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #7 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #8 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #9 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #10 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #11 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #12 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #13 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) Indirect leak of 40 byte(s) in 1 object(s) allocated from: #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105 #1 0x151be6b in make_unique<llvm::ValueSymbolTable> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/ADT/STLExtras.h:1349:29 #2 0x151be6b in llvm::Function::Function(llvm::FunctionType*, llvm::GlobalValue::LinkageTypes, unsigned int, llvm::Twine const&, llvm::Module*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/Function.cpp:241 #3 0x7c4006 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:16 #4 0x7c4006 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136 #5 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #6 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #7 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #8 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #9 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #10 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #11 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #12 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #13 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #14 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) SUMMARY: AddressSanitizer: 168 byte(s) leaked in 2 allocation(s). ``` See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11358/steps/check-llvm%20asan/logs/stdio for more information. Also introduces use-of-uninitialized-value in ConstantsTest.FoldGlobalVariablePtr: ``` ==7070==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x14e703c in User /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 #1 0x14e703c in Constant /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/Constant.h:44 #2 0x14e703c in llvm::GlobalValue::GlobalValue(llvm::Type*, llvm::Value::ValueTy, llvm::Use*, unsigned int, llvm::GlobalValue::LinkageTypes, llvm::Twine const&, unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalValue.h:78 #3 0x14e5467 in GlobalObject /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalObject.h:34:9 #4 0x14e5467 in llvm::GlobalVariable::GlobalVariable(llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, llvm::Twine const&, llvm::GlobalValue::ThreadLocalMode, unsigned int, bool) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/Globals.cpp:314 #5 0x6938f1 in llvm::(anonymous namespace)::ConstantsTest_FoldGlobalVariablePtr_Test::TestBody() /b/sanitizer-x86_64-linux-fast/build/llvm/unittests/IR/ConstantsTest.cpp:565:18 #6 0x1a240a1 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc #7 0x1a240a1 in testing::Test::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #8 0x1a26d26 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #9 0x1a2815f in testing::TestCase::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #10 0x1a43de8 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #11 0x1a42c47 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc #12 0x1a42c47 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #13 0x1a0dfba in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #14 0x1a0dfba in main /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #15 0x7f2081c412e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #16 0x4dff49 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/unittests/IR/IRTests+0x4dff49) SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 in User ``` See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30222/steps/check-llvm%20msan/logs/stdio for more information. llvm-svn: 355616
* Fix & re-enable test that intermittently failed in debug mode.Michael Platings2019-03-071-4/+5
| | | | | | The Value class and derivates will have uninitialized member variables if not created via operator new. llvm-svn: 355590
* Temporarily disable newly added test that fails in debug mode.Michael Platings2019-03-071-1/+1
| | | | llvm-svn: 355588
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-074-0/+173
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355585
* Revert "[IR][ARM] Add function pointer alignment to datalayout"Mitch Phillips2019-03-064-173/+0
| | | | | | | | | | | | | This reverts commit 2391bfca97290181ae65796ea6da135d1b6d037b. This reverts rL355522 (https://reviews.llvm.org/D57335). Kills buildbots that use '-Werror' with the following error: /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm/lib/IR/Value.cpp:657:7: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default] See buildbots http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30200/steps/check-llvm%20asan/logs/stdio for more information. llvm-svn: 355537
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-064-0/+173
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355522
* [OptRemarks] Make OptRemarks more generic: rename OptRemarks to RemarksFrancis Visoiu Mistrih2019-03-055-441/+445
| | | | | | | | | | | | | | | Getting rid of the name "optimization remarks" for anything that involves handling remarks on the client side. It's safer to do this now, before we get stuck with that name in all the APIs and public interfaces we decide to export to users in the future. This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now generates `libRemarks.dylib` instead of `libOptRemarks.dylib`. Differential Revision: https://reviews.llvm.org/D58535 llvm-svn: 355439
* [Subtarget] Merge ProcSched and ProcDesc arrays in MCSubtargetInfo into a ↵Craig Topper2019-03-051-1/+1
| | | | | | | | | | | | single array. These arrays are both keyed by CPU name and go into the same tablegenerated file. Merge them so we only need to store keys once. This also removes a weird space saving quirk where we used the ProcDesc.size() to create to build an ArrayRef for ProcSched. Differential Revision: https://reviews.llvm.org/D58939 llvm-svn: 355431
* PHI nodes are not `FPMathOperator` sSanjoy Das2019-03-051-0/+9
| | | | | | | | | | | | | | Reviewers: chandlerc, arsenm Reviewed By: arsenm Subscribers: wdng, arsenm, mcrosier, jlebar, bixia, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58887 llvm-svn: 355362
* [ValueTracking] Known bits support for unsigned saturating add/subNikita Popov2019-03-011-0/+71
| | | | | | | | | | | | | | | | We have two sources of known bits: 1. For adds leading ones of either operand are preserved. For sub leading zeros of LHS and leading ones of RHS become leading zeros in the result. 2. The saturating math is a select between add/sub and an all-ones/ zero value. As such we can carry out the add/sub known bits calculation, and only preseve the known one/zero bits respectively. Differential Revision: https://reviews.llvm.org/D58329 llvm-svn: 355223
* [CommandLine] Allow grouping options which can have values.Igor Kudrin2019-03-011-1/+172
| | | | | | | | | | | | | | | | This patch allows all forms of values for options to be used at the end of a group. With the fix, it is possible to follow the way GNU binutils tools handle grouping options better. For example, the -j option can be used with objdump in any of the following ways: $ objdump -d -j .text a.o $ objdump -d -j.text a.o $ objdump -dj .text a.o $ objdump -dj.text a.o Differential Revision: https://reviews.llvm.org/D58711 llvm-svn: 355185
* [CommandLine] Do not crash if an option has both ValueRequired and Grouping.Igor Kudrin2019-03-011-0/+22
| | | | | | | | | | | | If an option, which requires a value, has a `cl::Grouping` formatting modifier, it works well as far as it is used at the end of a group, or as a separate argument. However, if the option appears accidentally in the middle of a group, the program just crashes. This patch prints an error message instead. Differential Revision: https://reviews.llvm.org/D58499 llvm-svn: 355184
* [PGO] Context sensitive PGO (part 2)Rong Xu2019-02-282-6/+6
| | | | | | | | | | | Part 2 of CSPGO changes (mostly related to ProfileSummary). Note that I use a default parameter in setProfileSummary() and getSummary(). This is to break the dependency in clang. I will make the parameter explicit after changing clang in a separated patch. Differential Revision: https://reviews.llvm.org/D54175 llvm-svn: 355131
* Fix IR/Analysis layering issue with OptBisectRichard Trieu2019-02-281-1/+6
| | | | | | | | | | | | | OptBisect is in IR due to LLVMContext using it. However, it uses IR units from Analysis as well. This change moves getDescription functions from OptBisect to their respective IR units. Generating names for IR units will now be up to the callers, keeping the Analysis IR units in Analysis. To prevent unnecessary string generation, isEnabled function is added so that callers know when the description needs to be generated. Differential Revision: https://reviews.llvm.org/D58406 llvm-svn: 355068
* [Memory] Add basic support for large/huge memory pagesAlexandre Ganea2019-02-281-0/+16
| | | | | | | | | | | | | | | | | This patch introduces Memory::MF_HUGE_HINT which indicates that allocateMappedMemory() shall return a pointer to a large memory page. However the flag is a hint because we're not guaranteed in any way that we will get back a large memory page. There are several restrictions: - Large/huge memory pages aren't enabled by default on modern OSes (Windows 10 and Linux at least), and should be manually enabled/reserved. - Once enabled, it should be kept in mind that large pages are physical only, they can't be swapped. - Memory fragmentation can affect the availability of large pages, especially after running the OS for a long time and/or running along many other applications. Memory::allocateMappedMemory() will fallback to 4KB pages if it can't allocate 2MB large pages (if Memory::MF_HUGE_HINT is provided) Currently, Memory::MF_HUGE_HINT only works on Windows. The hint will be ignored on Linux, 4KB pages will always be returned. Differential Revision: https://reviews.llvm.org/D58718 llvm-svn: 355065
* GlobalISel: Implement fewerElementsVector for phiMatt Arsenault2019-02-281-0/+94
| | | | llvm-svn: 355048
* [MemorySSA] Make insertDef insert corresponding phi nodes.Alina Sbirlea2019-02-271-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The original assumption for the insertDef method was that it would not materialize Defs out of no-where, hence it will not insert phis needed after inserting a Def. However, when cloning an instruction (use case used in LICM), we do materialize Defs "out of no-where". If the block receiving a Def has at least one other Def, then no processing is needed. If the block just received its first Def, we must check where Phi placement is needed. The only new usage of insertDef is in LICM, hence the trigger for the bug. But the original goal of the method also fails to apply for the move() method. If we move a Def from the entry point of a diamond to either the left or right blocks, then the merge block must add a phi. While this usecase does not currently occur, or may be viewed as an incorrect transformation, MSSA must behave corectly given the scenario. Resolves PR40749 and PR40754. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58652 llvm-svn: 355040
* [DebugInfo] add SectionedAddress to DebugInfo interfaces.Alexey Lapshin2019-02-272-105/+146
| | | | | | | | | | | | | | | | | That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703 "wrong line number info for obj file compiled with -ffunction-sections" bug. The problem happened with only .o files. If object file contains several .text sections then line number information showed incorrectly. The reason for this is that DwarfLineTable could not detect section which corresponds to specified address(because address is the local to the section). And as the result it could not select proper sequence in the line table. The fix is to pass SectionIndex with the address. So that it would be possible to differentiate addresses from various sections. With this fix llvm-objdump shows correct line numbers for disassembled code. Differential review: https://reviews.llvm.org/D58194 llvm-svn: 354972
* [DWARFFormValue] Cleanup DWARFFormValue interface. (NFC)Jonas Devlieghere2019-02-272-104/+99
| | | | | | | | | | DWARFFormValues can be created from a data extractor or by passing its value directly. Until now this was done by member functions that modified an existing object's internal state. This patch replaces a subset of these methods with static method that return a new DWARFFormValue. llvm-svn: 354941
* [ARM] Add Cortex-M35PLuke Cheeseman2019-02-261-1/+3
| | | | | | | | | | - Add LLVM backend support for Cortex-M35P - Documentation can be found at https://developer.arm.com/products/processors/cortex-m/cortex-m35p Differentail Revision: https://reviews.llvm.org/D57763 llvm-svn: 354868
* [AArch64] Add support for Cortex-A76 and Cortex-A76AELuke Cheeseman2019-02-251-2/+26
| | | | | | | | - Add LLVM backend support for Cortex-A76 and Cortex-A76AE - Documentation can be found at https://developer.arm.com/products/processors/cortex-a/cortex-a76 llvm-svn: 354788
* Try again to fix memory leak in r354692Daniel Sanders2019-02-231-2/+4
| | | | | | The previous one didn't fix everything. llvm-svn: 354719
* Fix memory leak in r354692Daniel Sanders2019-02-231-2/+2
| | | | llvm-svn: 354712
* Restore ability for C++ API users to Enable IPRA.Daniel Sanders2019-02-222-0/+75
| | | | | | | | | | | | | | | | | | | Summary: Prior to r310876 one of our out-of-tree targets was enabling IPRA by modifying the TargetOptions::EnableIPRA. This no longer works on current trunk since the useIPRA() hook overrides any values that are set in advance. This patch adjusts the behaviour of the hook so that API users and useIPRA() can both enable it but useIPRA() cannot disable it if the API user already enabled it. Reviewers: arsenm Reviewed By: arsenm Subscribers: wdng, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D38043 llvm-svn: 354692
* BreakCriticalEdges: Update PostDominatorTreeMatt Arsenault2019-02-221-0/+29
| | | | llvm-svn: 354673
* [DTU] Refine the interface and logic of applyUpdatesChijun Sima2019-02-221-25/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch separates two semantics of `applyUpdates`: 1. User provides an accurate CFG diff and the dominator tree is updated according to the difference of `the number of edge insertions` and `the number of edge deletions` to infer the status of an edge before and after the update. 2. User provides a sequence of hints. Updates mentioned in this sequence might never happened and even duplicated. Logic changes: Previously, removing invalid updates is considered a side-effect of deduplication and is not guaranteed to be reliable. To handle the second semantic, `applyUpdates` does validity checking before deduplication, which can cause updates that have already been applied to be submitted again. Then, different calls to `applyUpdates` might cause unintended consequences, for example, ``` DTU(Lazy) and Edge A->B exists. 1. DTU.applyUpdates({{Delete, A, B}, {Insert, A, B}}) // User expects these 2 updates result in a no-op, but {Insert, A, B} is queued 2. Remove A->B 3. DTU.applyUpdates({{Delete, A, B}}) // DTU cancels this update with {Insert, A, B} mentioned above together (Unintended) ``` But by restricting the precondition that updates of an edge need to be strictly ordered as how CFG changes were made, we can infer the initial status of this edge to resolve this issue. Interface changes: The second semantic of `applyUpdates` is separated to `applyUpdatesPermissive`. These changes enable DTU(Lazy) to use the first semantic if needed, which is quite useful in `transforms/utils`. Reviewers: kuhar, brzycki, dmgreen, grosser Reviewed By: brzycki Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58170 llvm-svn: 354669
* [DTU] Deprecate insertEdge*/deleteEdge*Chijun Sima2019-02-221-13/+18
| | | | | | | | | | | | | | | | Summary: This patch converts all existing `insertEdge*/deleteEdge*` to `applyUpdates` and marks `insertEdge*/deleteEdge*` as deprecated. Reviewers: kuhar, brzycki Reviewed By: kuhar, brzycki Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58443 llvm-svn: 354652
* Add partial implementation of std::to_address() as llvm::to_address()Daniel Sanders2019-02-201-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Following on from the review for D58088, this patch provides the prerequisite to_address() implementation that's needed to have pointer_iterator support unique_ptr. The late bound return should be removed once we move to C++14 to better align with the C++20 declaration. Also, this implementation can be removed once we move to C++20 where it's defined as std::to_addres() The std::pointer_traits<>::to_address(p) variations of these overloads has not been implemented. Reviewers: dblaikie, paquette Reviewed By: dblaikie Subscribers: dexonsmith, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58421 llvm-svn: 354491
* GlobalISel: Implement moreElementsVector for bit opsMatt Arsenault2019-02-191-0/+40
| | | | llvm-svn: 354345
* GlobalISel: Fix double count of offset for irregular vector breakdownsMatt Arsenault2019-02-181-0/+48
| | | | | | | Fixes cases with odd vectors that break into multiple requested size pieces. llvm-svn: 354280
* [NFC] Make Optional<T> trivially copyable when T is trivially copyableSerge Guelton2019-02-181-0/+21
| | | | | | | | | | | This is a follow-up to r354246 and a reimplementation of https://reviews.llvm.org/D57097?id=186600 that should not trigger any UB thanks to the use of an union. This may still be subject to the problem solved by std::launder, but I'm unsure how it interacts whith union. /me plans to revert if this triggers any relevant bot failure. At least this validates in Release mode with clang 6.0.1 and gcc 4.8.5. llvm-svn: 354264
* Revert r354199: Make Optional<T> Trivially Copyable when T is trivially ↵Serge Guelton2019-02-161-7/+0
| | | | | | copyable llvm-svn: 354200
* Make Optional<T> Trivially Copyable when T is trivially copyableSerge Guelton2019-02-161-0/+7
| | | | | | | This is another attempt in the process, works nicely on my setup, let's check how it behaves on other targets. llvm-svn: 354199
* Speculatively revert r354051 "Recommit Optional specialization for trivially ↵Hans Wennborg2019-02-151-20/+0
| | | | | | | | | | | | | | | | | | | | | copyable types" and r354055 "Optional specialization for trivially copyable types, part2" These are suspected to cause Clang to get miscompiled on Ubuntu 14.04 (Trusty) which uses GCC 4.8.4. Reverting for an hour to see if this helps. See llvm-commits thread. > Recommit Optional specialization for trivially copyable types > > Unfortunately the original code gets misscompiled by GCC (at least 8.1), > this is a tentative workaround using std::memcpy instead of inplace new > for trivially copyable types. I'll revert if it breaks. > > Original revision: https://reviews.llvm.org/D57097 llvm-svn: 354126
* GlobalISel: Add alignment to LegalityQuery MMOsMatt Arsenault2019-02-141-0/+49
| | | | | | | This allows targets to specify the minimum alignment required for the load/store. llvm-svn: 354071
* Recommit Optional specialization for trivially copyable typesSerge Guelton2019-02-141-0/+20
| | | | | | | | | | Unfortunately the original code gets misscompiled by GCC (at least 8.1), this is a tentative workaround using std::memcpy instead of inplace new for trivially copyable types. I'll revert if it breaks. Original revision: https://reviews.llvm.org/D57097 llvm-svn: 354051
* Reapply [VFS] Allow multiple RealFileSystem instances with independent CWDs.Sam McCall2019-02-141-1/+86
| | | | | | | | | | This reverts commit r351091. The original mac breakages are addressed by ensuring the root directory we're working from is fully symlink-resolved before starting. Differential Revision: https://reviews.llvm.org/D58169 llvm-svn: 354026
* Revert r353962Serge Guelton2019-02-131-20/+0
| | | | | | | Specialization of Optional for trivially copyable types yields failure on the buildbots I fail to reproduce locally. Better safe than sorry, reverting. llvm-svn: 353982
* Re-commit rL353927, patch includedSerge Guelton2019-02-131-0/+20
| | | | | | | | | | | | | | | Make llvm::Optional<T> trivially copyable when T is trivially copyable This is an ever-recurring issue (see https://bugs.llvm.org/show_bug.cgi?id=39427 and https://bugs.llvm.org/show_bug.cgi?id=35978) but I believe that thanks to https://reviews.llvm.org/D54472 we can now ship a decent implementation of this. Basically the fact that llvm::is_trivially_copyable has a consistent behavior across compilers should prevent any ABI issue, and using in-place new instead of memcpy should keep compiler bugs away. This patch is slightly different from the original revision https://reviews.llvm.org/rL353927 but achieves the same goal. It just avoids going through std::conditional which may the code more explicit. llvm-svn: 353962
* Revert r353927Serge Guelton2019-02-131-20/+0
| | | | llvm-svn: 353940
* Missing headerSerge Guelton2019-02-131-0/+2
| | | | llvm-svn: 353933
* Make llvm::Optional<T> trivially copyable when T is trivially copyableSerge Guelton2019-02-131-0/+20
| | | | | | | | | | | | This is an ever-recurring issue (see https://bugs.llvm.org/show_bug.cgi?id=39427 and https://bugs.llvm.org/show_bug.cgi?id=35978) but I believe that thanks to https://reviews.llvm.org/D54472 we can now ship a decent implementation of this. Basically the fact that llvm::is_trivially_copyable has a consistent behavior across compilers should prevent any ABI issue, and using in-place new instead of memcpy should keep compiler bugs away. Differential Revision: https://reviews.llvm.org/D57097 llvm-svn: 353927
* [MemorySSA & LoopPassManager] Add remaining book keeping [NFCI].Alina Sbirlea2019-02-121-0/+2
| | | | | | | | Add plumbing to get MemorySSA in the remaining loop passes. Also update unit test to add the dependency. [EnableMSSALoopDependency remains disabled]. llvm-svn: 353901
* Update files that were mistakenly added with the old file header to theChandler Carruth2019-02-111-4/+3
| | | | | | new one. llvm-svn: 353665
* Update files that were mistakenly added with the old file header.Chandler Carruth2019-02-111-4/+3
| | | | llvm-svn: 353664
* [CodeExtractor] Restore outputs after creating exit stubsVedant Kumar2019-02-081-6/+37
| | | | | | | | | | | | | | | | | When CodeExtractor saves the result of InvokeInst at the first insertion point of the 'normal destination' basic block, this block can be omitted in the outlined region, so store is placed outside of the function. The suggested solution is to process saving outputs after creating exit stubs for new function, and stores will be placed in that blocks before return in this case. Patch by Sergei Kachkov! Fixes llvm.org/PR40455. Differential Revision: https://reviews.llvm.org/D57919 llvm-svn: 353562
* GlobalISel: Try to make legalize rules more useful for vectorsMatt Arsenault2019-02-072-0/+181
| | | | | | | Mostly keep the existing functions on scalars, but add versions which also operate based on the vector element size. llvm-svn: 353430
* Move DomTreeUpdater from IR to AnalysisRichard Trieu2019-02-065-6/+6
| | | | | | | | DomTreeUpdater depends on headers from Analysis, but is in IR. This is a layering violation since Analysis depends on IR. Relocate this code from IR to Analysis to fix the layering violation. llvm-svn: 353265
OpenPOWER on IntegriCloud