This repository was archived by the owner on Feb 5, 2019. It is now read-only.
Release 36@227537 #28
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
------------------------------------------------------------------------ r226075 | sanjoy | 2015-01-14 17:46:09 -0800 (Wed, 14 Jan 2015) | 10 lines Fix PR22222 The bug was introduced in r225282. r225282 assumed that sub X, Y is the same as add X, -Y. This is not correct if we are going to upgrade the sub to sub nuw. This change fixes the issue by making the optimization ignore sub instructions. Differential Revision: http://reviews.llvm.org/D6979 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226193 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226182 | joerg | 2015-01-15 09:59:02 -0800 (Thu, 15 Jan 2015) | 2 lines Support @plt loads on 32bit x86. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226203 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226212 91177308-0d34-0410-b5e6-96231b3b80d8
Somehow I missed this review comment until now... git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226213 91177308-0d34-0410-b5e6-96231b3b80d8
r225644 is a revert of r225644. A fixed version for trunk is being reviewed, but there is no need to rush this into 3.6. Original message: Revert "Add r224985 back with two fixes." This reverts commit r225644 while I debug a regression. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226354 91177308-0d34-0410-b5e6-96231b3b80d8
It should get more testing on trunk before going into a release. Original message: Use the integrated assembler by default on SPARC. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226355 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226170 | vkalintiris | 2015-01-15 15:36:04 +0000 (Thu, 15 Jan 2015) | 7 lines Fix the C-API MCJIT test for 32-bit big endian machines. Avoid using unions for storing the return value from LLVMGetGlobalValueAddress() and LLVMGetFunctionAddress() and accessing it as a pointer through another pointer member. This causes problems on 32-bit big endian machines since the pointer gets the higher part of the return value of the aforementioned functions. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226378 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226171 | dsanders | 2015-01-15 15:41:03 +0000 (Thu, 15 Jan 2015) | 11 lines [mips] Fix a typo in the compare patterns for MIPS32r6/MIPS64r6. Summary: The patterns intended for the SETLE node were actually matching the SETLT node. Reviewers: atanasyan, sstankovic, vmedic Reviewed By: vmedic Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6997 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226379 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226582 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226473 | garious | 2015-01-19 09:40:05 -0800 (Mon, 19 Jan 2015) | 8 lines [AArch64] Implement GHC calling convention Original patch by Luke Iannini. Minor improvements and test added by Erik de Castro Lopo. Differential Revision: http://reviews.llvm.org/D6877 From: Erik de Castro Lopo <[email protected]> ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226604 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226186 | marek.olsak | 2015-01-15 13:42:40 -0500 (Thu, 15 Jan 2015) | 2 lines R600/SI: Don't select SI-only VOP3 opcodes on VI ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226714 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226187 | marek.olsak | 2015-01-15 13:42:44 -0500 (Thu, 15 Jan 2015) | 2 lines R600/SI: Add common class VOPAnyCommon ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226715 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r226188 | marek.olsak | 2015-01-15 13:42:51 -0500 (Thu, 15 Jan 2015) | 7 lines
R600/SI: Don't shrink instructions whose e32 encoding doesn't exist
v2: modify hasVALU32BitEncoding instead
v3: - add pseudoToMCOpcode helper to AMDGPUInstInfo, which is used by both
hasVALU32BitEncoding and AMDGPUMCInstLower::lower
- report an error if a pseudo can't be lowered
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226717 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226189 | marek.olsak | 2015-01-15 13:42:55 -0500 (Thu, 15 Jan 2015) | 6 lines R600/SI: Add V_READLANE_B32 and V_WRITELANE_B32 for VI These are VOP3-only on VI. The new multiclass doesn't define VOP3 versions of VOP2 instructions. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226718 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226190 | marek.olsak | 2015-01-15 13:43:01 -0500 (Thu, 15 Jan 2015) | 2 lines R600/SI: Use 64-bit encoding by default for opcodes that are VOP3-only on VI ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226719 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226191 | marek.olsak | 2015-01-15 13:43:06 -0500 (Thu, 15 Jan 2015) | 11 lines R600/SI: Unify VOP2 instructions which are VOP3-only on VI This removes some duplicated classes and definitions. These instructions are defined: _e32 // pseudo _e32_si _e64 // pseudo _e64_si _e64_vi ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226720 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226226 | Matthew.Arsenault | 2015-01-15 18:17:03 -0500 (Thu, 15 Jan 2015) | 5 lines R600/SI: Fix trailing comma with modifiers Instructions with 1 operand can still use source modifiers, so make sure we don't print an extra comma afterwards. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226721 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226583 | thomas.stellard | 2015-01-20 12:49:41 -0500 (Tue, 20 Jan 2015) | 5 lines R600/SI: Update SIInstrInfo:verifyInstruction() after r225662 Now that we have our own custom register operand types, we need to handle them in the verifiier. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226722 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226584 | thomas.stellard | 2015-01-20 12:49:43 -0500 (Tue, 20 Jan 2015) | 6 lines R600/SI: Don't store scratch buffer frame index in MUBUF offset field We don't have a good way of legalizing this if the frame index offset is more than the 12-bits, which is size of MUBUF's offset field, so now we store the frame index in the vaddr field. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226723 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226585 | thomas.stellard | 2015-01-20 12:49:45 -0500 (Tue, 20 Jan 2015) | 5 lines R600/SI: Add kill flag when copying scratch offset to a register This allows us to re-use the same register for the scratch offset when accessing large private arrays. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226724 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226586 | thomas.stellard | 2015-01-20 12:49:47 -0500 (Tue, 20 Jan 2015) | 6 lines R600/SI: Use external symbols for scratch buffer We were passing the scratch buffer address to the shaders via user sgprs, but now we use external symbols and have the driver patch the shader using reloc information. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226725 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226591 | thomas.stellard | 2015-01-20 14:24:31 -0500 (Tue, 20 Jan 2015) | 2 lines R600/SI: Remove stray debugging code from r226586 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226726 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226596 | thomas.stellard | 2015-01-20 14:33:02 -0500 (Tue, 20 Jan 2015) | 2 lines R600/SI: Fix simple-loop.ll test ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226727 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226597 | thomas.stellard | 2015-01-20 14:33:04 -0500 (Tue, 20 Jan 2015) | 5 lines R600/SI: Add subtarget feature to enable VGPR spilling for all shader types This is disabled by default, but can be enabled with the subtarget feature: 'vgpr-spilling' ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226728 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226755 | sanjoy | 2015-01-21 16:48:47 -0800 (Wed, 21 Jan 2015) | 11 lines Make ScalarEvolution less aggressive with respect to no-wrap flags. ScalarEvolution currently lowers a subtraction recurrence to an add recurrence with the same no-wrap flags as the subtraction. This is incorrect because `sub nsw X, Y` is not the same as `add nsw X, -Y` and `sub nuw X, Y` is not the same as `add nuw X, -Y`. This patch fixes the issue, and adds two test cases demonstrating the bug. Differential Revision: http://reviews.llvm.org/D7081 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226839 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226708 | majnemer | 2015-01-21 14:32:04 -0800 (Wed, 21 Jan 2015) | 4 lines InstCombine: Don't strip bitcasts off of callsites marked 'thunk' The return type of a thunk is meaningless, we just want the arguments and return value to be forwarded. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226854 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226711 | jroelofs | 2015-01-21 14:39:43 -0800 (Wed, 21 Jan 2015) | 8 lines Fix load-store optimizer on thumbv4t Thumbv4t does not have lo->lo copies other than MOVS, and that can't be predicated. So emit MOVS when needed and bail if there's a predicate. http://reviews.llvm.org/D6592 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@226918 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226664 | tnorthover | 2015-01-21 07:43:31 -0800 (Wed, 21 Jan 2015) | 7 lines AArch64: add backend option to reserve x18 (platform register) AAPCS64 says that it's up to the platform to specify whether x18 is reserved, and a first step on that way is to add a flag controlling it. From: Andrew Turner <[email protected]> ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227150 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227188 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227005 | dsanders | 2015-01-24 14:35:11 +0000 (Sat, 24 Jan 2015) | 38 lines [mips] Fix 'jumpy' debug line info around calls. Summary: At the moment, address calculation is taking the debug line info from the address node (e.g. TargetGlobalAddress). When a function is called multiple times, this results in output of the form: .loc $first_call_location .. address calculation .. .. function call .. .. address calculation .. .loc $second_call_location .. function call .. .loc $first_call_location .. address calculation .. .loc $third_call_location .. function call .. This patch makes address calculations for function calls take the debug line info for the call node and results in output of the form: .loc $first_call_location .. address calculation .. .. function call .. .loc $second_call_location .. address calculation .. .. function call .. .loc $third_call_location .. address calculation .. .. function call .. All other address calculations continue to use the address node. Test Plan: Fixes test/DebugInfo/multiline.ll on a mips host. Subscribers: dblaikie, llvm-commits Differential Revision: http://reviews.llvm.org/D7050 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227193 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227260 | compnerd | 2015-01-27 14:57:35 -0800 (Tue, 27 Jan 2015) | 4 lines SymbolRewriter: prevent unnecessary rewrite The rewrite for the pattern based rewrite is unnecessary if the existing name matches the pattern. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227323 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227261 | compnerd | 2015-01-27 14:57:39 -0800 (Tue, 27 Jan 2015) | 6 lines SymbolRewriter: allow rewriting with comdats COMDATs must be identically named to the symbol. When support for COMDATs was introduced, the symbol rewriter was not updated, resulting in rewriting failing for symbols which were placed into COMDATs. This corrects the behaviour and adds test cases for this. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227324 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227294 | chandlerc | 2015-01-27 20:57:56 -0800 (Tue, 27 Jan 2015) | 23 lines [LPM] Stop using the string based preservation API. It is an abomination. For starters, this API is incredibly slow. In order to lookup the name of a pass it must take a memory fence to acquire a pointer to the managed static pass registry, and then potentially acquire locks while it consults this registry for information about what passes exist by that name. This stops the world of LLVMs in your process no matter how little they cared about the result. To make this more joyful, you'll note that we are preserving many passes which *do not exist* any more, or are not even analyses which one might wish to have be preserved. This means we do all the work only to say "nope" with no error to the user. String-based APIs are a *bad idea*. String-based APIs that cannot produce any meaningful error are an even worse idea. =/ I have a patch that simply removes this API completely, but I'm hesitant to commit it as I don't really want to perniciously break out-of-tree users of the old pass manager. I'd rather they just have to migrate to the new one at some point. If others disagree and would like me to kill it with fire, just say the word. =] ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227328 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227299 | chandlerc | 2015-01-28 01:47:21 -0800 (Wed, 28 Jan 2015) | 48 lines [LPM] A targeted but somewhat horrible fix to the legacy pass manager's querying of the pass registry. The pass manager relies on the static registry of PassInfo objects to perform all manner of its functionality. I don't understand why it does much of this. My very vague understanding is that this registry is touched both during static initialization *and* while each pass is being constructed. As a consequence it is hard to make accessing it not require a acquiring some lock. This lock ends up in the hot path of setting up, tearing down, and invaliditing analyses in the legacy pass manager. On most systems you can observe this as a non-trivial % of the time spent in 'ninja check-llvm'. However, I haven't really seen it be more than 1% in extreme cases of compiling more real-world software, including LTO. Unfortunately, some of the GPU JITs are seeing this taking essentially all of their time because they have very small IR running through a small pass pipeline very many times (at least, this is the vague understanding I have of it). This patch tries to minimize the cost of looking up PassInfo objects by leveraging the fact that the objects themselves are immutable and they are allocated separately on the heap and so don't have their address change. It also requires a change I made the last time I tried to debug this problem which removed the ability to de-register a pass from the registry. This patch creates a single access path to these objects inside the PMTopLevelManager which memoizes the result of querying the registry. This is somewhat gross as I don't really know if PMTopLevelManager is the *right* place to put it, and I dislike using a mutable member to memoize things, but it seems to work. For long-lived pass managers this should completely eliminate the cost of acquiring locks to look into the pass registry once the memoized cache is warm. For 'ninja check' I measured about 1.5% reduction in CPU time and in total time on a machine with 32 hardware threads. For normal compilation, I don't know how much this will help, sadly. We will still pay the cost while we populate the memoized cache. I don't think it will hurt though, and for LTO or compiles with many small functions it should still be a win. However, for tight loops around a pass manager with many passes and small modules, this will help tremendously. On the AArch64 backend I saw nearly 50% reductions in time to complete 2000 cycles of spinning up and tearing down the pipeline. Measurements from Owen of an actual long-lived pass manager show more along the lines of 10% improvements. Differential Revision: http://reviews.llvm.org/D7213 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227331 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227300 | chandlerc | 2015-01-28 01:52:14 -0800 (Wed, 28 Jan 2015) | 34 lines
[LPM] Rip all of ManagedStatic and ThreadLocal out of the pretty stack
tracing code.
Managed static was just insane overhead for this. We took memory fences
and external function calls in every path that pushed a pretty stack
frame. This includes a multitude of layers setting up and tearing down
passes, the parser in Clang, everywhere. For the regression test suite
or low-overhead JITs, this was contributing to really significant
overhead.
Even the LLVM ThreadLocal is really overkill here because it uses
pthread_{set,get}_specific logic, and has careful code to both allocate
and delete the thread local data. We don't actually want any of that,
and this code in particular has problems coping with deallocation. What
we want is a single TLS pointer that is valid to use during global
construction and during global destruction, any time we want. That is
exactly what every host compiler and OS we use has implemented for
a long time, and what was standardized in C++11. Even though not all of
our host compilers support the thread_local keyword, we can directly use
the platform-specific keywords to get the minimal functionality needed.
Provided this limited trial survives the build bots, I will move this to
Compiler.h so it is more widely available as a light weight if limited
alternative to the ThreadLocal class. Many thanks to David Majnemer for
helping me think through the implications across platforms and craft the
MSVC-compatible syntax.
The end result is *substantially* faster. When running llc in a tight
loop over a small IR file targeting the aarch64 backend, this improves
its performance by over 10% for me. It also seems likely to fix the
remaining regressions seen by JIT users with threading enabled.
This may actually have more impact on real-world compile times due to
the use of the pretty stack tracing utility throughout the rest of Clang
or LLVM, but I've not collected any detailed measurements.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227332 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes pr22351. Original messages: r226026: Fix handling of extern_weak. This was broken by r225983 r226031: Fix linking of shared libraries. In shared libraries the plugin can see non-weak declarations that are still undefined. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227344 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227250 | ab | 2015-01-27 13:52:16 -0800 (Tue, 27 Jan 2015) | 31 lines [SimplifyLibCalls] Don't confuse strcpy_chk for stpcpy_chk. This was introduced in a faulty refactoring (r225640, mea culpa): the tests weren't testing the return values, so, for both __strcpy_chk and __stpcpy_chk, we would return the end of the buffer (matching stpcpy) instead of the beginning (for strcpy). The root cause was the prefix "__" being ignored when comparing, which made us always pick LibFunc::stpcpy_chk. Pass the LibFunc::Func directly to avoid this kind of error. Also, make the testcases as explicit as possible to prevent this. The now-useful testcases expose another, entangled, stpcpy problem, with the further simplification. This was introduced in a refactoring (r225640) to match the original behavior. However, this leads to problems when successive simplifications generate several similar instructions, none of which are removed by the custom replaceAllUsesWith. For instance, InstCombine (the main user) doesn't erase the instruction in its custom RAUW. When trying to simplify say __stpcpy_chk: - first, an stpcpy is created (fortified simplifier), - second, a memcpy is created (normal simplifier), but the stpcpy call isn't removed. - third, InstCombine later revisits the instructions, and simplifies the first stpcpy to a memcpy. We now have two memcpys. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227346 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226945 | thomas.stellard | 2015-01-23 17:05:45 -0500 (Fri, 23 Jan 2015) | 9 lines R600/SI: Move i64 -> v2i32 load promotion into AMDGPUDAGToDAGISel::Select() We used to do this promotion during DAG legalization, but this caused an infinite loop in ExpandUnalignedLoad() because it assumed that i64 loads were legal if i64 was a legal type. It also seems better to report i64 loads as legal, since they actually are and we were just promoting them to simplify our tablegen files. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227364 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r226970 | thomas.stellard | 2015-01-23 18:59:08 -0500 (Fri, 23 Jan 2015) | 2 lines R600/SI: Emit .hsa.version section for amdhsa OS ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227365 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227085 | joerg | 2015-01-26 03:41:48 -0800 (Mon, 26 Jan 2015) | 13 lines
The canonical CPU variant for ARM according to config.guess uses a
suffix it seems:
# ./config.guess
earmv7hfeb-unknown-netbsd7.99.4
Extend the triple parsing to support this. Avoid running the ARM parser
multiple times because StringSwitch is not lazy.
Reviewers: Renato Golin, Tim Northover
Differential Revision: http://reviews.llvm.org/D7166
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227394 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227319 | bsteinbr | 2015-01-28 08:35:59 -0800 (Wed, 28 Jan 2015) | 10 lines Fix LLVMSetMetadata and LLVMAddNamedMetadataOperand for single value MDNodes Summary: MetadataAsValue uses a canonical format that strips the MDNode if it contains only a single constant value. This triggers an assertion when trying to cast the value to a MDNode. Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7165 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227475 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227339 | bsteinbr | 2015-01-28 10:32:31 -0800 (Wed, 28 Jan 2015) | 3 lines Fix build breakage caused by memory leaks in llvm-c-test I accidently introduced those in r227319. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227477 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227290 | dblaikie | 2015-01-27 18:34:53 -0800 (Tue, 27 Jan 2015) | 1 line PR22356: DebugInfo: Handle the size of a member where the type of that member is a typedef (or other sugar) of a declaration. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227492 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r227491 | spatel | 2015-01-29 12:51:49 -0800 (Thu, 29 Jan 2015) | 13 lines [GVN] don't propagate equality comparisons of FP zero (PR22376) In http://reviews.llvm.org/D6911, we allowed GVN to propagate FP equalities to allow some simple value range optimizations. But that introduced a bug when comparing to -0.0 or 0.0: these compare equal even though they are not bitwise identical. This patch disallows propagating zero constants in equality comparisons. Fixes: http://llvm.org/bugs/show_bug.cgi?id=22376 Differential Revision: http://reviews.llvm.org/D7257 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227537 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().
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (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. |
|
Merged as https://github.com/rust-lang/llvm/tree/rust-llvm-2015-01-30, 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.
This updates llvm to the current state of the release_36 branch. Compared to #27 this contains a patch that fixes a LLVM C API regression which is required for rustc to work.
Also, I dropped the PassInfo patch in favor of the upstream changes which should hopefully solve the problem equally well.