This repository has been archived by the owner on Feb 5, 2019. It is now read-only.
Update to release_36@229036 #36
Closed
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
------------------------------------------------------------------------ r228565 | majnemer | 2015-02-08 22:31:31 -0800 (Sun, 08 Feb 2015) | 3 lines MC: Calculate intra-section symbol differences correctly for COFF This fixes PR22060. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228667 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r228656 | chandlerc | 2015-02-09 18:25:56 -0800 (Mon, 09 Feb 2015) | 16 lines [x86] Fix PR22524: the DAG combiner was incorrectly handling illegal nodes when folding bitcasts of constants. We can't fold things and then check after-the-fact whether it was legal. Once we have formed the DAG node, arbitrary other nodes may have been collapsed to it. There is no easy way to go back. Instead, we need to test for the specific folding cases we're interested in and ensure those are legal first. This could in theory make this less powerful for bitcasting from an integer to some vector type, but AFAICT, that can't actually happen in the SDAG so its fine. Now, we *only* whitelist specific int->fp and fp->int bitcasts for post-legalization folding. I've added the test case from the PR. (Also as a note, this does not appear to be in 3.6, no backport needed) ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228787 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r228760 | majnemer | 2015-02-10 15:09:43 -0800 (Tue, 10 Feb 2015) | 3 lines EarlyCSE: It isn't safe to CSE across synchronization boundaries This fixes PR22514. ------------------------------------------------------------------------ ------------------------------------------------------------------------ r228761 | majnemer | 2015-02-10 15:11:02 -0800 (Tue, 10 Feb 2015) | 1 line EarlyCSE: Add check lines for test added in r228760 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228790 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r228793 | bogner | 2015-02-10 18:52:44 -0800 (Tue, 10 Feb 2015) | 12 lines InstrProf: Lower coverage mappings by setting their sections appropriately Add handling for __llvm_coverage_mapping to the InstrProfiling pass. We need to make sure the constant and any profile names it refers to are in the correct sections, which is easier and cleaner to do here where we have to know about profiling sections anyway. This is really tricky to test without a frontend, so I'm committing the test for the fix in clang. If anyone knows a good way to test this within LLVM, please let me know. Fixes PR22531. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228800 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r225904 | rnk | 2015-01-13 17:05:27 -0800 (Tue, 13 Jan 2015) | 27 lines CodeGen support for x86_64 SEH catch handlers in LLVM This adds handling for ExceptionHandling::MSVC, used by the x86_64-pc-windows-msvc triple. It assumes that filter functions have already been outlined in either the frontend or the backend. Filter functions are used in place of the landingpad catch clause type info operands. In catch clause order, the first filter to return true will catch the exception. The C specific handler table expects the landing pad to be split into one block per handler, but LLVM IR uses a single landing pad for all possible unwind actions. This patch papers over the mismatch by synthesizing single instruction BBs for every catch clause to fill in the EH selector that the landing pad block expects. Missing functionality: - Accessing data in the parent frame from outlined filters - Cleanups (from __finally) are unsupported, as they will require outlining and parent frame access - Filter clauses are unsupported, as there's no clear analogue in SEH In other words, this is the minimal set of changes needed to write IR to catch arbitrary exceptions and resume normal execution. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D6300 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228891 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r228899 | chandlerc | 2015-02-11 18:30:56 -0800 (Wed, 11 Feb 2015) | 28 lines [slp] Fix a nasty bug in the SLP vectorizer that Joerg pointed out. Apparently some code finally started to tickle this after my canonicalization changes to instcombine. The bug stems from trying to form a vector type out of scalars that aren't compatible at all. In this example, from x86_mmx values. The code in the vectorizer that checks for reasonable types whas checking for aggregates or vectors, but there are lots of other types that should just never reach the vectorizer. Debugging this was made more confusing by the lie in an assert in VectorType::get() -- it isn't that the types are *primitive*. The types must be integer, pointer, or floating point types. No other types are allowed. I've improved the assert and added a helper to the vectorizer to handle the element type validity checks. It now re-uses the VectorType static function and then further excludes weird target-specific types that we probably shouldn't be touching here (x86_fp80 and ppc_fp128). Neither of these are really reachable anyways (neither 80-bit nor 128-bit things will get vectorized) but it seems better to just eagerly exclude such nonesense. I've added a test case, but while it definitely covers two of the paths through this code there may be more paths that would benefit from test coverage. I'm not familiar enough with the SLP vectorizer to synthesize test cases for all of these, but was able to update the code itself by inspection. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228940 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r228842 | jvoung | 2015-02-11 08:12:50 -0800 (Wed, 11 Feb 2015) | 17 lines Gold-plugin: Broaden scope of get/release_input_file to scope of Module. Summary: Move calls to get_input_file and release_input_file out of getModuleForFile(). Otherwise release_input_file may end up unmapping a view of the file while the view is still being used by the Module (on 32-bit hosts). Fix for PR22482. Test Plan: Add test using --no-map-whole-files. Reviewers: rafael, nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7539 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228942 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r228957 | bsteinbr | 2015-02-12 13:04:22 -0800 (Thu, 12 Feb 2015) | 14 lines Fix a crash in the assumption cache when inlining indirect function calls Summary: Instances of the AssumptionCache are per function, so we can't re-use the same AssumptionCache instance when recursing in the CallAnalyzer to analyze a different function. Instead we have to pass the AssumptionCacheTracker to the CallAnalyzer so it can get the right AssumptionCache on demand. Reviewers: hfinkel Subscribers: llvm-commits, hans Differential Revision: http://reviews.llvm.org/D7533 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228965 91177308-0d34-0410-b5e6-96231b3b80d8
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see CONTRIBUTING.md for more information. |
------------------------------------------------------------------------ r228979 | majnemer | 2015-02-12 15:26:26 -0800 (Thu, 12 Feb 2015) | 8 lines X86: Don't crash if we can't decode the pshufb mask Constant pool entries are uniqued by their contents regardless of their type. This means that a pshufb can have a shuffle mask which isn't a simple array of bytes. The code path which attempts to decode the mask didn't check for failure, causing PR22559. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228983 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226588 | adrian | 2015-01-20 10:03:37 -0800 (Tue, 20 Jan 2015) | 1 line Add an assertion and prefer a crash over an infinite loop. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228984 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226616 | adrian | 2015-01-20 14:37:25 -0800 (Tue, 20 Jan 2015) | 2 lines DebugLocs without a scope should fail the verification. Follow-up to r226588. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228985 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r228969 | hfinkel | 2015-02-12 14:43:52 -0800 (Thu, 12 Feb 2015) | 7 lines [SDAG] Don't try to use FP_EXTEND/FP_ROUND for int<->fp promotions The PowerPC backend has long promoted some floating-point vector operations (such as select) to integer vector operations. Unfortunately, this behavior was broken by r216555. When using FP_EXTEND/FP_ROUND for promotions, we must check that both the old and new types are floating-point types. Otherwise, we must use BITCAST as we did prior to r216555 for everything. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228986 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r229029 | chandlerc | 2015-02-12 18:30:01 -0800 (Thu, 12 Feb 2015) | 16 lines [IC] Fix a bug with the instcombine canonicalizing of loads and propagating of metadata. We were propagating !nonnull metadata even when the newly formed load is no longer of a pointer type. This is clearly broken and results in LLVM failing the verifier and aborting. This patch just restricts the propagation of !nonnull metadata to when we actually have a pointer type. This bug report and the initial version of this patch was provided by Charles Davis! Many thanks for finding this! We still need to add logic to round-trip the metadata correctly if we combine from pointer types to integer types and then back by using range metadata for the integer type loads. But this is the minimal and safe version of the patch, which is important so we can backport it into 3.6. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229036 91177308-0d34-0410-b5e6-96231b3b80d8
This pass is not Rust-specific, in that all of its transformations are intended to be correct for arbitrary LLVM IR, but it targets idioms found in IR generated by `rustc`, e.g. heavy use of `inbounds` GEPs.
Since the NullCheckElimination pass has a similar intent to the CorrelatedValuePropagation pass, I decided to run it right after the both places that the latter runs.
Teach the NullCheckElimination pass about recurrences involving inbounds GEPs. This allows the pass to optimize null checks from most uses of single slice and vector iterators. This still isn't sufficient to eliminate null checks from uses of multiple iterators with zip().
…builds with assertions enabld Since the PassInfo cache does a regular, uncached, slow lookup for the asserted condition, it's not very effective *cough* when assertions are enabled. Since disabling these assertions gives quite a nice perf boost and it's not really worse than the patch we had previously, let's just do that.
|
Pushed as https://github.com/rust-lang/llvm/tree/rust-llvm-2015-02-13, thanks! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fixes the crash seen with rust-lang/rust#21886