forked from rust-lang/llvm
-
Notifications
You must be signed in to change notification settings - Fork 3
Rebase on top of current Rust LLVM fork #5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Conversation
This file contains hidden or 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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292602 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292603 91177308-0d34-0410-b5e6-96231b3b80d8
…t honor the recently added file-based API git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292731 91177308-0d34-0410-b5e6-96231b3b80d8
…ry Analysis" pass git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292732 91177308-0d34-0410-b5e6-96231b3b80d8
…uction attachments" git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292760 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r291858 | eugenis | 2017-01-12 15:03:03 -0800 (Thu, 12 Jan 2017) | 1 line [asan] Refactor instrumentation of globals. ------------------------------------------------------------------------ ------------------------------------------------------------------------ r291859 | eugenis | 2017-01-12 15:26:20 -0800 (Thu, 12 Jan 2017) | 6 lines [asan] Don't overalign global metadata. Other than on COFF with incremental linking, global metadata should not need any extra alignment. Differential Revision: https://reviews.llvm.org/D28628 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292802 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292583 | dannyb | 2017-01-19 22:38:41 -0800 (Thu, 19 Jan 2017) | 4 lines NewGVN: Fix PR 31682, an overactive assert. Part of the assert has been left active for further debugging. The other part has been turned into a stat for tracking for the moment. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292810 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292820 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292323 | pzheng | 2017-01-17 17:03:29 -0800 (Tue, 17 Jan 2017) | 9 lines [test-release.sh] Add Polly to the list of projects Reviewers: zinob, hans, grosser Reviewed By: hans, grosser Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28712 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292831 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292758 | spatel | 2017-01-22 09:06:12 -0800 (Sun, 22 Jan 2017) | 4 lines [x86] avoid crashing with illegal vector type (PR31672) https://llvm.org/bugs/show_bug.cgi?id=31672 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292832 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292467 | compnerd | 2017-01-18 18:58:46 -0800 (Wed, 18 Jan 2017) | 7 lines llvm-cxxfilt: filter out invalid manglings c++filt does not attempt to demangle symbols which do not match its expected format. This means that the symbol must start with _Z or ___Z (block invocation function extension). Any other symbols are returned as is. Note that this is different from the behaviour of __cxa_demangle which will demangle fragments. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292861 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r291909 | compnerd | 2017-01-13 08:25:33 -0800 (Fri, 13 Jan 2017) | 9 lines ARM: match GCC's behaviour for builtins GCC changes the CC between the user-code and the builtins based on the value of `-target` rather than `-mfloat-abi`. When a HF target is used, the VFP variant of the AAPCS CC is used. Otherwise, the AAPCS variant is used. In all cases, the AEABI functions use the AAPCS CC. Adjust the calling convention based on the target. Resolves PR30543! ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292951 91177308-0d34-0410-b5e6-96231b3b80d8
… with side effects) if it has a param with the 'returned' attribute
------------------------------------------------------------------------ r292444 | mkuper | 2017-01-18 15:05:58 -0800 (Wed, 18 Jan 2017) | 7 lines Revert r291670 because it introduces a crash. r291670 doesn't crash on the original testcase from PR31589, but it crashes on a slightly more complex one. PR31589 has the new reproducer. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293070 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r293025 | ahatanak | 2017-01-24 22:21:51 -0800 (Tue, 24 Jan 2017) | 29 lines [SimplifyCFG] Do not sink and merge inline-asm instructions. Conservatively disable sinking and merging inline-asm instructions as doing so can potentially create arguments that cannot satisfy the inline-asm constraints. For example, SimplifyCFG used to do the following transformation: (before) if.then: %0 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 8) br label %if.end if.else: %1 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 6) br label %if.end (after) %.sink = select i1 %tobool, i32 6, i32 8 %0 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 %.sink) This would result in a crash in the backend since only immediate integer operands are permitted for constraint "n". rdar://problem/30110806 Differential Revision: https://reviews.llvm.org/D29111 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293074 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r293088 | tnorthover | 2017-01-25 12:58:26 -0800 (Wed, 25 Jan 2017) | 5 lines SDag: fix how initial loads are formed when splitting vector ops. Later code expects the vector loads produced to be directly concatenable, which means we shouldn't pad anything except the last load produced with UNDEF. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293103 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292651 | jvesely | 2017-01-20 13:24:26 -0800 (Fri, 20 Jan 2017) | 8 lines AMDGPU/R600: Serialize vector trunc stores to private AS Add DUMMY_CHAIN SDNode to denote stores of interest Bugzilla: https://llvm.org/bugs/show_bug.cgi?id=28915 Bugzilla: https://llvm.org/bugs/show_bug.cgi?id=30411 Differential Revision: https://reviews.llvm.org/D27964 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293118 91177308-0d34-0410-b5e6-96231b3b80d8
…ct lane size (2,4,8 or 16). This prevents i1xN vector constant creation from getting erroneously expanded up to a nonexisting Bool1x128 type.
no_bool1x128
------------------------------------------------------------------------ r293000 | thomas.stellard | 2017-01-24 17:25:13 -0800 (Tue, 24 Jan 2017) | 15 lines AMDGPU add support for spilling to a user sgpr pointed buffers Summary: This lets you select which sort of spilling you want, either s[0:1] or 64-bit loads from s[0:1]. Patch By: Dave Airlie Reviewers: nhaehnle, arsenm, tstellarAMD Reviewed By: arsenm Subscribers: mareko, llvm-commits, kzhuravl, wdng, yaxunl, tony-tye Differential Revision: https://reviews.llvm.org/D25428 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293240 91177308-0d34-0410-b5e6-96231b3b80d8
…etadataLoader::MetadataLoaderImpl::parseOneMetadata. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293292 91177308-0d34-0410-b5e6-96231b3b80d8
…GEP" git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293294 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292516 | rserge | 2017-01-19 12:24:23 -0800 (Thu, 19 Jan 2017) | 14 lines [XRay][Arm] Repair XRay table emission on Arm32 and add tests to identify such problem earlier Summary: Emission of XRay table was occasionally disabled for Arm32, but this bug was not then detected because earlier (also by mistake) testing of XRay was occasionally disabled on 32-bit Arm targets. This patch should fix that problem and detect such problems in the future. This patch is one of a series, see also - https://reviews.llvm.org/D28623 Reviewers: rengolin, dberris Reviewed By: dberris Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown Differential Revision: https://reviews.llvm.org/D28624 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293295 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292712 | ctopper | 2017-01-20 22:59:35 -0800 (Fri, 20 Jan 2017) | 1 line [X86] Add test cases that show bad commuting being allowed to create a phsub operation. ------------------------------------------------------------------------ ------------------------------------------------------------------------ r292713 | ctopper | 2017-01-20 22:59:38 -0800 (Fri, 20 Jan 2017) | 3 lines [X86] Don't allow commuting to form phsub operations. Fixes PR31714. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293299 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r293259 | compnerd | 2017-01-26 19:41:53 -0800 (Thu, 26 Jan 2017) | 11 lines ARM: fix vectorized division on WoA The Windows on ARM target uses custom division for normal division as the backend needs to insert division-by-zero checks. However, it is designed to only handle non-vectorized division. ARM has custom lowering for vectorized division as that can avoid loading registers with the values and invoke a division routine for each one, preferring to lower using NEON instructions. Fall back to the custom lowering for the NEON instructions if we encounter a vectorized division. Resolves PR31778! ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293306 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292472 | arsenm | 2017-01-18 22:04:12 -0800 (Wed, 18 Jan 2017) | 5 lines AMDGPU: Remove modifiers from v_div_scale_* They seem to produce nonsense results when used. This should be applied to the release branch. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293317 91177308-0d34-0410-b5e6-96231b3b80d8
the nonnull attribute distinct from rewriting it into an assume. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306358 91177308-0d34-0410-b5e6-96231b3b80d8
This is based heavily on the work done ni D34285. I mostly wanted to do test cleanup for the author to save them some time, but I had a really hard time understanding why it was so hard to write better test cases for these issues. The problem is that because SROA does a second rewrite of the loads and because we *don't* propagate !nonnull for non-pointer loads, we first introduced invalid !nonnull metadata and then stripped it back off just in time to avoid most ways of this PR manifesting. Moving to the more careful utility only fixes this by changing the predicate to look at the new load's type rather than the target type. However, that *does* fix the bug, and the utility is much nicer including adding range metadata to model the nonnull property after a conversion to an integer. However, we have bigger problems because we don't actually propagate *range* metadata, and the utility to do this extracted from instcombine isn't really in good shape to do this currently. It *only* handles the case of copying range metadata from an integer load to a pointer load. It doesn't even handle the trivial cases of propagating from one integer load to another when they are the same width! This utility will need to be beefed up prior to using in this location to get the metadata to fully survive. And even then, we need to go and teach things to turn the range metadata into an assume the way we do with nonnull so that when we *promote* an integer we don't lose the information. All of this will require a new test case that looks kind-of like `preserve-nonnull.ll` does here but focuses on range metadata. It will also likely require more testing because it needs to correctly handle changes to the integer width, especially as SROA actively tries to change the integer width! Last but not least, I'm a little worried about hooking the range metadata up here because the instcombine logic for converting from a range metadata *to* a nonnull metadata node seems broken in the face of non-zero address spaces where null is not mapped to the integer `0`. So that probably needs to get fixed with test cases both in SROA and in instcombine to cover it. But this *does* extract the core PR fix from D34285 of preventing the !nonnull metadata from being propagated in a broken state just long enough to feed into promotion and crash value tracking. On D34285 there is some discussion of zero-extend handling because it isn't necessary. First, the new load size covers all of the non-undef (ie, possibly initialized) bits. This may even extend past the original alloca if loading those bits could produce valid data. The only way its valid for us to zero-extend an integer load in SROA is if the original code had a zero extend or those bits were undef. And we get to assume things like undef *never* satifies nonnull, so non undef bits can participate here. No need to special case the zero-extend handling, it just falls out correctly. The original credit goes to Ariel Ben-Yehuda! I'm mostly landing this to save a few rounds of trivial edits fixing style issues and test case formulation. Differental Revision: D34285 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306379 91177308-0d34-0410-b5e6-96231b3b80d8
Preserve nonnull metadata on Loads through SROA & mem2reg
This makes sure we get the same redefinition rules regardless of who is printing (asm parser, codegen) and to what (asm, obj). This fixes an unintentional regression in r293936. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294752 91177308-0d34-0410-b5e6-96231b3b80d8
Move some error handling down to MCStreamer.
Cherry-picked from 0226ba2 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301313 91177308-0d34-0410-b5e6-96231b3b80d8
It caused the register to later be dead, which would trigger a verifier error. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301368 91177308-0d34-0410-b5e6-96231b3b80d8
It is sufficient to skip emission of these arguments as we have nothing to actually pass through the function call. The AVR-GCC reference has nothing to say about zero-sized arguments, presumably because C/C++ doesn't support them. This means we don't have to worry about ABI differences. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294119 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Authored by Florian Zeitz. This implements the missing stacksave/stackrestore intrinsics via expansion. Output of `llc -O0 -march=avr ~/devel/llvm/test/CodeGen/Generic/stacksave-restore.ll` for sanity checking (comments mine): ``` .text .file ".../llvm/test/CodeGen/Generic/stacksave-restore.ll" .globl test .p2align 1 .type test,@function test: ; @test ; BB#0: push r28 push r29 in r28, 61 in r29, 62 sbiw r28, 4 in r0, 63 cli out 62, r29 out 63, r0 out 61, r28 in r18, 61 in r19, 62 mov r20, r22 mov r21, r23 in r30, 61 in r31, 62 lsl r22 rol r23 lsl r22 rol r23 in r26, 61 in r27, 62 sub r26, r22 sbc r27, r23 andi r26, 252 in r0, 63 cli out 62, r27 out 63, r0 out 61, r26 in r0, 63 cli out 62, r31 out 63, r0 out 61, r30 in r30, 61 in r31, 62 sub r30, r22 sbc r31, r23 andi r30, 252 in r0, 63 cli out 62, r31 out 63, r0 out 61, r30 std Y+3, r24 ; 2-byte Folded Spill std Y+4, r25 ; 2-byte Folded Spill mov r24, r26 mov r25, r27 in r0, 63 cli out 62, r19 out 63, r0 out 61, r18 std Y+1, r20 ; 2-byte Folded Spill std Y+2, r21 ; 2-byte Folded Spill adiw r28, 4 in r0, 63 cli out 62, r29 out 63, r0 out 61, r28 pop r29 pop r28 ret .Lfunc_end0: .size test, .Lfunc_end0-test ``` Reviewers: dylanmckay Reviewed By: dylanmckay Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29553 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294146 91177308-0d34-0410-b5e6-96231b3b80d8
…offset Before this, the LDS/STS instructions would have their opcodes overwritten while linking. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301782 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us do bit rotations of variable amount. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301794 91177308-0d34-0410-b5e6-96231b3b80d8
Because it was a callee-saved register, we automatically generated code to spill and unspill its original value so that it is restored after the function returns. The problem is that this code was being generated before the epilogue. The epilogue itself uses the Y register, which could be prematurely restored by the CSR restoration process. This removes R29R28 from the CSR list and changes the prologue/epilogue code to handle it explicitly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301887 91177308-0d34-0410-b5e6-96231b3b80d8
A recent commit I made made it so that we only did this for signal or interrupt handlers. This broke normal functions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301893 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302017 91177308-0d34-0410-b5e6-96231b3b80d8
… same spot Contributed by Dr. Gergő Érdi. Fixes a bug. Raised from (avr-rust/rust-legacy-fork#49). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302973 91177308-0d34-0410-b5e6-96231b3b80d8
(avr-rust/rust-legacy-fork#50) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304283 91177308-0d34-0410-b5e6-96231b3b80d8
When generating code for a shift loop, check the shift amount against the literal value 0, not R0 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304284 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: CPI does not read the status register, but only writes it. Reviewers: dylanmckay Reviewed By: dylanmckay Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33223 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304116 91177308-0d34-0410-b5e6-96231b3b80d8
…e same spot as the original MBB (avr-rust/rust-legacy-fork#62)
(avr-rust/rust-legacy-fork#63 avr-rust/rust-legacy-fork#64) [AVR] Use 1-byte alignment for all data types (avr-rust/rust-legacy-fork#64)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307056 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, if a basic block ended with a FRMIDX instruction, we would end up doing something like this. *std::next(MBB.end()) Which would hit an error: "Assertion `!NodePtr->isKnownSentinel()' failed."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307617 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Carl Peto. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307888 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311620 91177308-0d34-0410-b5e6-96231b3b80d8
Also enables '__do_clear_bss'. These functions are automaticalled called by the CRT if they are declared. We need these to be called otherwise RAM will start completely uninitialised, even though we need to copy RAM variables from progmem to RAM. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312905 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the issue (rust-lang#75) with floating-point comparisons generating broken code. By default, LLVM assumes these comparisons return 32-bit values, but ours are 8-bit.
The base of this PR is |
You can't merge in a rebase, anyway 😸 |
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.
Related to avr-rust/rust-legacy-fork#78