October 2017 bump. #4
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ing. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315395 91177308-0d34-0410-b5e6-96231b3b80d8
…ting. We can just write directly to the raw_ostream. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315399 91177308-0d34-0410-b5e6-96231b3b80d8
Of course, casting an unsigned value too large for 'int' is UB. So, write out the ternary. LLVM folds it to ADD anyway. Fixes the warning from r303693 a different way. Thanks to Erich Keane for pointing this out! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315406 91177308-0d34-0410-b5e6-96231b3b80d8
…ptr. MCObjectStreamer owns its MCAsmBackend -- this fixes the types to reflect that, and allows us to remove another instance of MCObjectStreamer's weird "holding ownership via someone else's reference" trick. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315410 91177308-0d34-0410-b5e6-96231b3b80d8
… headers leaving only program headers and loadable segment data elf utils implements a particularly extreme form of stripping that I'd like to support. eu-strip has an option called "strip-sections" that removes all section headers and leaves only program headers and the segment data. I have implemented this option partly as a test but mainly because in Fuchsia we would like to use this option to minimize the size of our executables. The other strip options that are on my list include --strip-all and --strip-debug. This is a preliminary implementation that I'd like to start using in Fuchsia builds if possible. This change implements such a stripping option for llvm-objcopy Differential Revision: https://reviews.llvm.org/D38335 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315412 91177308-0d34-0410-b5e6-96231b3b80d8
Should fix mingw bot. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315413 91177308-0d34-0410-b5e6-96231b3b80d8
… section headers leaving only program headers and loadable segment data" This reverts commit rL315412 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315417 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR34908. Patch by Alex Crichton! Differential Revision: https://reviews.llvm.org/D38765 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315429 91177308-0d34-0410-b5e6-96231b3b80d8
IRCE should not apply when the safe iteration range is proved to be empty. In this case we do unneeded job creating pre/post loops and then never go to the main loop. This patch makes IRCE not apply to empty safe ranges, adds test for this situation and also modifies one of existing tests where it used to happen slightly. Reviewed By: anna Differential Revision: https://reviews.llvm.org/D38577 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315437 91177308-0d34-0410-b5e6-96231b3b80d8
Sinking of unordered atomic load into loop must be disallowed because it turns a single load into multiple loads. The relevant section of the documentation is: http://llvm.org/docs/Atomics.html#unordered, specifically the Notes for Optimizers section. Here is the full text of this section: > Notes for optimizers > In terms of the optimizer, this **prohibits any transformation that > transforms a single load into multiple loads**, transforms a store into > multiple stores, narrows a store, or stores a value which would not be > stored otherwise. Some examples of unsafe optimizations are narrowing > an assignment into a bitfield, rematerializing a load, and turning loads > and stores into a memcpy call. Reordering unordered operations is safe, > though, and optimizers should take advantage of that because unordered > operations are common in languages that need them. Patch by Daniil Suchkov! Reviewed By: reames Differential Revision: https://reviews.llvm.org/D38392 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315438 91177308-0d34-0410-b5e6-96231b3b80d8
…ss control flow to successors This patch fixes the miscompile that happens when PRE hoists loads across guards and other instructions that don't always pass control flow to their successors. PRE is now prohibited to hoist across such instructions because there is no guarantee that the load standing after such instruction is still valid before such instruction. For example, a load from under a guard may be invalid before the guard in the following case: int array[LEN]; ... guard(0 <= index && index < LEN); use(array[index]); Differential Revision: https://reviews.llvm.org/D37460 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315440 91177308-0d34-0410-b5e6-96231b3b80d8
Adding this test files now so after another commit that will add a new pattern for TESTM and TESTNM instructions will show the improvemnts that have been done. Change-Id: If3908b7f91897d764053312365a2bc1de78b291d git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315443 91177308-0d34-0410-b5e6-96231b3b80d8
This adds debug tracing to the table-generated assembly instruction matcher, enabled by the -debug-only=asm-matcher option. The changes in the target AsmParsers are to add an MCInstrInfo reference under a consistent name, so that we can use it from table-generated code. This was already being used this way for targets that use deprecation warnings, but 5 targets did not have it, and Hexagon had it under a different name to the other backends. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315445 91177308-0d34-0410-b5e6-96231b3b80d8
Use range_loop where it simplifies. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315446 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315447 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315448 91177308-0d34-0410-b5e6-96231b3b80d8
… free from MC. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315449 91177308-0d34-0410-b5e6-96231b3b80d8
…lgen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315450 91177308-0d34-0410-b5e6-96231b3b80d8
Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D38620 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315451 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315454 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: https://reviews.llvm.org/D38779 Patch by Chih-Mao Chen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315455 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds timestamp verification for swiftmodule files. - A new flag is provided to allows us to continue testing of the code for embedding the__swift_ast. (git doesn't maintain timestamps) - Adds a new test for fat (arm) binaries. Differential revision: https://reviews.llvm.org/D38686 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315456 91177308-0d34-0410-b5e6-96231b3b80d8
The NumFixedArgs field of CallLoweringInfo is used by TargetLowering::LowerCallTo to determine whether a given argument is passed using the vararg calling convention or not (specifically, to set IsFixed for each ISD::OutputArg). Firstly, CallLoweringInfo::setLibCallee and CallLoweringInfo::setCallee both incorrectly set NumFixedArgs based on the _previous_ args list. Secondly, TargetLowering::LowerCallTo failed to increment NumFixedArgs when modifying the argument list so a pointer is passed for the return value. If your backend uses the IsFixed property or directly accesses NumFixedArgs, it is _possible_ this change could result in codegen changes (although the previous behaviour would have been incorrect). No such cases have been identified during code review for any in-tree architecture. Differential Revision: https://reviews.llvm.org/D37898 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315457 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r315456. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315458 91177308-0d34-0410-b5e6-96231b3b80d8
Eg:
insert v4i32 V, (v2i16 X), 2 --> shuffle v8i16 V', X', {0,1,2,3,8,9,6,7}
This is a generalization of the IR fold in D38316 to handle insertion into a non-undef vector.
We may want to abandon that one if we can't find value in squashing the more specific pattern sooner.
We're using the existing legal shuffle target hook to avoid AVX512 horror with vXi1 shuffles.
There may be room for improvement in the shuffle lowering here, but that would be follow-up work.
Differential Revision: https://reviews.llvm.org/D38388
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315460 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315461 91177308-0d34-0410-b5e6-96231b3b80d8
The pipeliner is generating a serial sequence that causes poor register allocation when a post-increment instruction appears prior to the use of the post-increment register. This occurs when there is a circular set of dependences involved with a sequence of instructions in the same cycle. In this case, there is no serialization of the parallel semantics that will not cause an additional register to be allocated. This patch fixes the problem by changing the instructions so that the post-increment instruction is used by the subsequent instruction, which enables the register allocator to make a better decision and not require another register. Patch by Brendon Cahoon. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315466 91177308-0d34-0410-b5e6-96231b3b80d8
…ores The software pipeliner and the packetizer try to break dependence between the post-increment instruction and the dependent memory instructions by changing the base register and the offset value. However, in some cases, the existing logic didn't work properly and created incorrect offset value. Patch by Jyotsna Verma. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315468 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: I don't think this is necessary with i1 being illegal now. Reviewers: RKSimon, zvi, guyblank Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38784 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315469 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315471 91177308-0d34-0410-b5e6-96231b3b80d8
… vectors (PR34947) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315825 91177308-0d34-0410-b5e6-96231b3b80d8
Avoid unnecessary std::string creations in the TreePredicateFn getters. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315826 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315828 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes cfe/trunk/test/Misc/backend-resource-limit-diagnostics.cl test after r315808 We may hit few other similar issues, but I want to discuss good solution offline. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315830 91177308-0d34-0410-b5e6-96231b3b80d8
It fails on mips git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315837 91177308-0d34-0410-b5e6-96231b3b80d8
GCC otherwise emits a "defined but not used" warning on the member function. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315838 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: GlobalISel and SelectionDAG require different code for the common load/store predicates due to differences in the representation. For example: SelectionDAG: (load<signext,i8>:i32 GPR32:$addr) // The <> denote properties of the SDNode that are not printed in the DAG GlobalISel: (G_SEXT:s32 (G_LOAD:s8 GPR32:$addr)) Even without that, differences in the IR (SDNode vs MachineInstr) require differences in the C++ predicate. This patch moves the implementation of the common load/store predicates into tablegen so that it can handle these differences. It's NFC for SelectionDAG since it emits equivalent code and it's NFC for GlobalISel since the rules involving the relevant predicates are still rejected by the importer. Depends on D36618 Reviewers: ab, qcolombet, t.p.northover, rovka, aditya_nandakumar Subscribers: llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D37443 Includes a partial revert of r315826 since this patch makes it necessary for getPredCode() to return a std::string and getImmCode() should have the same interface as getPredCode(). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315841 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: There is an important mismatch between ISD::LOAD and G_LOAD (and likewise for ISD::STORE and G_STORE). In SelectionDAG, ISD::LOAD is a non-atomic load and atomic loads are handled by a separate node. However, this is not true of GlobalISel's G_LOAD. For G_LOAD, the MachineMemOperand indicates the atomicity of the operation. As a result, this mapping must also add a predicate that checks for non-atomic MachineMemOperands. This is NFC since these nodes always have predicates in practice and are therefore always rejected at the moment. Depends on D37443 Reviewers: ab, qcolombet, t.p.northover, rovka, aditya_nandakumar Reviewed By: qcolombet Subscribers: kristof.beyls, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D37445 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315843 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315847 91177308-0d34-0410-b5e6-96231b3b80d8
…g masking ops. We should be able to fold constant conditions by converting to shuffles, but fixing that would break these tests in their current form. Since they are really trying to test masking ops, add a non-constant mask to the selects. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315848 91177308-0d34-0410-b5e6-96231b3b80d8
…th AVX512 instructions. Summary: It's better to use our shuffle lowering code to handle these than loading an immediate into a k-register. It really feels like this should be a DAG combine optimization rather than a lowering operation, but that's a problem for another day. Reviewers: RKSimon, delena, zvi Reviewed By: delena Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38932 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315849 91177308-0d34-0410-b5e6-96231b3b80d8
… the Loop Pass, NFC. This avoid code duplication and allow us to add the disable unroll metadata elsewhere. Differential Revision: https://reviews.llvm.org/D38928 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315850 91177308-0d34-0410-b5e6-96231b3b80d8
…solve PR34565 Differential Revision: https://reviews.llvm.org/D38359 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315851 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces code size for constructs like vtables or interrupt tables that refer to functions in global initializers. Differential Revision: https://reviews.llvm.org/D34805 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315852 91177308-0d34-0410-b5e6-96231b3b80d8
This can result in significant code size savings in some cases, e.g. an interrupt table all filled with the same assembly stub in a certain Cortex-M BSP results in code blowup by a factor of 2.5. Differential Revision: https://reviews.llvm.org/D34806 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315853 91177308-0d34-0410-b5e6-96231b3b80d8
…is causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315854 91177308-0d34-0410-b5e6-96231b3b80d8
There seems to be something missing here as shown in PR34471: https://bugs.llvm.org/show_bug.cgi?id=34471 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315855 91177308-0d34-0410-b5e6-96231b3b80d8
…tion for icmp (shr exact X, C1), C2 --> icmp X, (C2<<C1) Recommitting r314698. The bug exposed by this change should be fixed with: https://reviews.llvm.org/rL315579 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315857 91177308-0d34-0410-b5e6-96231b3b80d8
…tions In type inference, an empty type set for a specific hw mode is not an error. In earlier stages of the design it was, but having to use non- parameterized types with target intrinsics necessarily led to type contradictions: since the intrinsics used specific types, they were only valid for a specific hw mode, and the resulting type set for other modes ended up empty. To accommodate the existence of such intrinsics individual type sets were allowed to be empty as long as not all sets were empty. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315858 91177308-0d34-0410-b5e6-96231b3b80d8
…, and Knights Landing CPUs. Summary: I see nothing in Agner Fog's tables to indicate that this improved between Ivy Bridge and Haswell. It's also set for all Atom CPUs so I assume KNL should have it too. Reviewers: RKSimon, zvi, gadi.haber Reviewed By: gadi.haber Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38890 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315859 91177308-0d34-0410-b5e6-96231b3b80d8
…om lowering. Summary: This was impeding our ability to combine the extending shuffles with other shuffles as you can see from the test changes. There's one special case that needed to be added to use VZEXT directly for v8i8->v8i64 since the custom lowering requires v64i8. Reviewers: RKSimon, zvi, delena Reviewed By: delena Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38714 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315860 91177308-0d34-0410-b5e6-96231b3b80d8
…UILD The test requires a target for triple x86-64, and it fails in builds that do not have the X86 backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315861 91177308-0d34-0410-b5e6-96231b3b80d8
Turns out we have no patterns on the instructions that were using this feature flag for other reasons. These instructions are slow on all modern CPUs so it seems unlikely that we will spend any effort supporting these instructions going forward. So we might as well just kill of the feature flag and just fix up the comments. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315862 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: It's possible for a ComplexPattern to be used as an operator in a match pattern. This is used by the load/store patterns in AArch64 to name the suboperands returned by ComplexPattern predicate so that they can be broken apart and referenced independently in the result pattern. This patch adds support for this in order to enable the import of load/store patterns. Depends on D37445 Reviewers: ab, qcolombet, t.p.northover, rovka, aditya_nandakumar Reviewed By: qcolombet Subscribers: aemerson, javed.absar, igorb, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D37456 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315863 91177308-0d34-0410-b5e6-96231b3b80d8
…d as an operator A large number of bots are failing on an ambiguous constructor call. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315866 91177308-0d34-0410-b5e6-96231b3b80d8
…used as an operator Summary: It's possible for a ComplexPattern to be used as an operator in a match pattern. This is used by the load/store patterns in AArch64 to name the suboperands returned by ComplexPattern predicate so that they can be broken apart and referenced independently in the result pattern. This patch adds support for this in order to enable the import of load/store patterns. Depends on D37445 Hopefully fixed the ambiguous constructor that a large number of bots reported. Reviewers: ab, qcolombet, t.p.northover, rovka, aditya_nandakumar Reviewed By: qcolombet Subscribers: aemerson, javed.absar, igorb, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D37456 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315869 91177308-0d34-0410-b5e6-96231b3b80d8
Ninja doesn't seem to recognize a change in a CMakeLists.txt in a subdirectory, so r315861 is not having any effect. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315870 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR brings
LEGto 15 Oct 2017: a5204d048729 of llvm master.One thing to notice is that I discarded the original commits, made by @frasercrmck and @pasaulais and only took the actual changes that they introduced. I then applied it on top of what then was the top of the tree.
You might want to re-structure the commits, so they show the progress of
LEGbackend development better.I personally like the fact that all
LEGcommits sit at the front of the commit history. It might make it easier in future to bump it.