- 07 Aug, 2014 2 commits
-
-
Bill Wendling authored
```--------------------------------------------------------------------- r214481 | hfinkel | 2014-07-31 22:20:41 -0700 (Thu, 31 Jul 2014) | 38 lines [PowerPC] Generate unaligned vector loads using intrinsics instead of regular loads Altivec vector loads on PowerPC have an interesting property: They always load from an aligned address (by rounding down the address actually provided if necessary). In order to generate an actual unaligned load, you can generate two load instructions, one with the original address, one offset by one vector length, and use a special permutation to extract the bytes desired. When this was originally implemented, I generated these two loads using regular ISD::LOAD nodes, now marked as aligned. Unfortunately, there is a problem with this: The alignment of a load does not contribute to its identity, and SDNodes are uniqued. So, imagine that we have some unaligned load, L1, that is not aligned. The routine will create two loads, L1(aligned) and (L1+16)(aligned). Further imagine that there had already existed a load (L1+16)(unaligned) with the same chain operand as the load L1. When (L1+16)(aligned) is created as part of the lowering of L1, this load *is* also the (L1+16)(unaligned) node, just now marked as aligned (because the new alignment overwrites the old). But the original users of (L1+16)(unaligned) now get the data intended for the permutation yielding the data for L1, and (L1+16)(unaligned) no longer exists to get its own permutation-based expansion. This was PR19991. A second potential problem has to do with the MMOs on these loads, which can be used by AA during instruction scheduling to break chain-based dependencies. If the new "aligned" loads get the MMO from the original unaligned load, this does not represent the fact that it will load data from below the original address. Normally, this would not matter, but this load might be combined with another load pair for a previous vector, and then the dependency on the otherwise- ignored lower bytes can matter. To fix both problems, instead of generating the necessary loads using regular ISD::LOAD instructions, ppc_altivec_lvx intrinsics are used instead. These are provided with MMOs with a conservative address range. Unfortunately, I no longer have a failing test case (since PR19991 was reported, other changes in CodeGen have forced this bug back into hiding it again). Nevertheless, this should fix the underlying problem. ``` --------------------------------------------------------------------- llvm-svn: 215058
-
Bill Wendling authored
```--------------------------------------------------------------------- r215046 | rsmith | 2014-08-06 17:24:21 -0700 (Wed, 06 Aug 2014) | 19 lines Use -Rblah, not -Wblah, to control remark diagnostics. This was always the intent when we added remark support, but was never implemented in the general case, because the first -R flags didn't need it. (-Rpass= had special handling to accomodate its argument.) -Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark, or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything does not affect remarks, and -Reverything does not affect warnings or errors. The only "real" -R flag we have right now is -Rmodule-build; that flag is effectively renamed from -Wmodule-build to -Rmodule-build by this change. -Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and -Rno-pass by this change; it's not completely clear whether we intended to have a -Rpass (with no =pattern), but that is unchanged by this commit, other than the flag name. The default pattern is effectively one which matches no passes. In future, we may want to make the default pattern be .*, so that -Reverything works for -Rpass properly. ``` --------------------------------------------------------------------- llvm-svn: 215057
-
- 05 Aug, 2014 8 commits
-
-
Bill Schmidt authored
llvm-svn: 214927
-
Bill Schmidt authored
```--------------------------------------------------------------------- r214923 | wschmidt | 2014-08-05 15:47:25 -0500 (Tue, 05 Aug 2014) | 12 lines [PowerPC] Swap arguments and adjust shift count for vsldoi on little endian Commits r213915 and r214718 fix recognition of shuffle masks for vmrg* and vpku*um instructions for a little-endian target, by swapping the input arguments. The vsldoi instruction requires similar treatment, and also needs its shift count adjusted for little endian. Reviewed by Ulrich Weigand. This is a bug fix candidate for release 3.5 (and hopefully the last of those for PowerPC). ``` --------------------------------------------------------------------- llvm-svn: 214926
-
Tom Stellard authored
```--------------------------------------------------------------------- r214865 | thomas.stellard | 2014-08-05 10:40:52 -0400 (Tue, 05 Aug 2014) | 5 lines R600/SI: Avoid generating REGISTER_LOAD instructions. SI doesn't use REGISTER_LOAD anymore, but it was still hitting this code path for 8-bit and 16-bit private loads. ``` --------------------------------------------------------------------- llvm-svn: 214895
-
Tom Stellard authored
```--------------------------------------------------------------------- r214463 | thomas.stellard | 2014-07-31 20:32:28 -0400 (Thu, 31 Jul 2014) | 7 lines R600/SI: Fix incorrect commute operation in shrink instructions pass We were commuting the instruction by still shrinking it using the original opcode. NOTE: This is a candidate for the 3.5 branch. ``` --------------------------------------------------------------------- llvm-svn: 214894
-
Bill Wendling authored
llvm-svn: 214842
-
Bill Wendling authored
```--------------------------------------------------------------------- r213799 | grosbach | 2014-07-23 13:41:38 -0700 (Wed, 23 Jul 2014) | 5 lines X86: restrict combine to when type sizes are safe. The folding of unary operations through a vector compare and mask operation is only safe if the unary operation result is of the same size as its input. For example, it's not safe for [su]itofp from v4i32 to v4f64. ``` --------------------------------------------------------------------- llvm-svn: 214841
-
Bill Wendling authored
```--------------------------------------------------------------------- r214735 | ogoffart | 2014-08-04 10:28:11 -0700 (Mon, 04 Aug 2014) | 1 line Fix crash when accessing a property of an invalid interface ``` --------------------------------------------------------------------- llvm-svn: 214840
-
Bill Wendling authored
```--------------------------------------------------------------------- r214734 | ogoffart | 2014-08-04 10:28:05 -0700 (Mon, 04 Aug 2014) | 7 lines Fix crash when assiging to a property with an invalid type This is a regression from clang 3.4 Set the result to ExprError and returns true, rather than simply returns false because errors have been reported already and returning false show a confusing error ``` --------------------------------------------------------------------- llvm-svn: 214839
-
- 04 Aug, 2014 30 commits
-
-
Bill Schmidt authored
```--------------------------------------------------------------------- r214801 | wschmidt | 2014-08-04 18:21:26 -0500 (Mon, 04 Aug 2014) | 19 lines [PPC64LE] Fix wrong IR for vec_sld and vec_vsldoi My original LE implementation of the vsldoi instruction, with its altivec.h interfaces vec_sld and vec_vsldoi, produces incorrect shufflevector operations in the LLVM IR. Correct code is generated because the back end handles the incorrect shufflevector in a consistent manner. This patch and a companion patch for LLVM correct this problem by removing the fixup from altivec.h and the corresponding fixup from the PowerPC back end. Several test cases are also modified to reflect the now-correct LLVM IR. The vec_sums and vec_vsumsws interfaces in altivec.h are also fixed, because they used vec_perm calls intended to be recognized as vsldoi instructions. These vec_perm calls are now replaced with code that more clearly shows the intent of the transformation. ``` --------------------------------------------------------------------- llvm-svn: 214823
-
Bill Schmidt authored
llvm-svn: 214822
-
Bill Schmidt authored
```--------------------------------------------------------------------- r214800 | wschmidt | 2014-08-04 18:21:01 -0500 (Mon, 04 Aug 2014) | 13 lines [PPC64LE] Fix wrong IR for vec_sld and vec_vsldoi My original LE implementation of the vsldoi instruction, with its altivec.h interfaces vec_sld and vec_vsldoi, produces incorrect shufflevector operations in the LLVM IR. Correct code is generated because the back end handles the incorrect shufflevector in a consistent manner. This patch and a companion patch for Clang correct this problem by removing the fixup from altivec.h and the corresponding fixup from the PowerPC back end. Several test cases are also modified to reflect the now-correct LLVM IR. ``` --------------------------------------------------------------------- llvm-svn: 214821
-
Bill Schmidt authored
```--------------------------------------------------------------------- r214721 | uweigand | 2014-08-04 09:55:26 -0500 (Mon, 04 Aug 2014) | 4 lines [PowerPC] Add target triple to vec_urem_const.ll test case This should hopefully fix build bots on other architectures. ``` --------------------------------------------------------------------- llvm-svn: 214820
-
Bill Schmidt authored
```--------------------------------------------------------------------- r214718 | uweigand | 2014-08-04 08:53:40 -0500 (Mon, 04 Aug 2014) | 12 lines [PowerPC] Swap arguments to vpkuhum/vpkuwum on little-endian In commit r213915, Bill fixed little-endian usage of vmrgh* and vmrgl* by swapping the input arguments. As it turns out, the exact same fix is also required for the vpkuhum/vpkuwum patterns. This fixes another regression in llvmpipe when vector support is enabled. Reviewed by Bill Schmidt. ``` --------------------------------------------------------------------- llvm-svn: 214819
-
Bill Schmidt authored
```--------------------------------------------------------------------- r214716 | uweigand | 2014-08-04 08:27:12 -0500 (Mon, 04 Aug 2014) | 9 lines [PowerPC] MULHU/MULHS are not legal for vector types I ran into some test failures where common code changed vector division by constant into a multiply-high operation (MULHU). But these are not implemented by the back-end, so we failed to recognize the insn. Fixed by marking MULHU/MULHS as Expand for vector types. ``` --------------------------------------------------------------------- llvm-svn: 214818
-
Bill Schmidt authored
```--------------------------------------------------------------------- r214714 | uweigand | 2014-08-04 08:13:57 -0500 (Mon, 04 Aug 2014) | 19 lines [PowerPC] Fix and improve vector comparisons This patch refactors code generation of vector comparisons. This fixes a wrong code-gen bug for ISD::SETGE for floating-point types, and improves generated code for vector comparisons in general. Specifically, the patch moves all logic deciding how to implement vector comparisons into getVCmpInst, which gets two extra boolean outputs indicating to its caller whether its needs to swap the input operands and/or negate the result of the comparison. Apart from implementing these two modifications as directed by getVCmpInst, there is no need to ever implement vector comparisons in any other manner; in particular, there is never a need to perform two separate comparisons (e.g. one for equal and one for greater-than, as code used to do before this patch). Reviewed by Bill Schmidt. ``` --------------------------------------------------------------------- llvm-svn: 214817
-
Hans Wennborg authored
Excluding the /Zp option, because that was added after the 3.5 branch. ------------------------------------------------------------------------ r214777 | hans | 2014-08-04 14:07:58 -0700 (Mon, 04 Aug 2014) | 1 line UsersManual: update clang-cl options ------------------------------------------------------------------------ llvm-svn: 214778
-
Bill Wendling authored
```--------------------------------------------------------------------- r214291 | sylvestre | 2014-07-30 01:33:21 -0700 (Wed, 30 Jul 2014) | 11 lines Use __linux__ macro throughout, instead of ocasional __linux. __linux is not universally defined across all standards versions, compilers and architectures. Specifically at C99 and up, it's not defined in GCC on powerpc platform. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28314 Bugzilla: http://llvm.org/bugs/show_bug.cgi?id=20380 Patch by Dimitri John Ledkov <dimitri.ledkov@canonical.com> ``` --------------------------------------------------------------------- llvm-svn: 214766
-
Bill Wendling authored
```--------------------------------------------------------------------- r214060 | brad | 2014-07-27 18:57:32 -0700 (Sun, 27 Jul 2014) | 2 lines Add missing override keyword to OpenBSD IsIntegratedAssemblerDefault(). ``` --------------------------------------------------------------------- llvm-svn: 214765
-
Bill Wendling authored
------------------------------------------------------------------------ llvm-svn: 214764
-
Bill Wendling authored
```--------------------------------------------------------------------- r213834 | rsmith | 2014-07-23 19:27:39 -0700 (Wed, 23 Jul 2014) | 4 lines Take the canonical type when forming a canonical template argument with 'nullptr' value. Fixes profiling of such template arguments to always give the same value. ``` --------------------------------------------------------------------- llvm-svn: 214751
-
Bill Wendling authored
```--------------------------------------------------------------------- r213913 | rsmith | 2014-07-24 18:12:44 -0700 (Thu, 24 Jul 2014) | 4 lines PR20445: Properly transform the initializer in a CXXNewExpr rather than running it through the normal TreeTransform logic for Exprs (which will strip off implicit parts of the initialization and never re-create them). ``` --------------------------------------------------------------------- llvm-svn: 214750
-
Bill Wendling authored
```--------------------------------------------------------------------- r213966 | brad | 2014-07-25 12:28:44 -0700 (Fri, 25 Jul 2014) | 4 lines Fix arc4random detection. Patch by Pascal Stumpf. ``` --------------------------------------------------------------------- llvm-svn: 214749
-
Bill Wendling authored
```--------------------------------------------------------------------- r213999 | tstellar | 2014-07-25 18:05:20 -0700 (Fri, 25 Jul 2014) | 1 line R600: Add processor type for Mullins ``` --------------------------------------------------------------------- llvm-svn: 214748
-
Bill Wendling authored
------------------------------------------------------------------------ llvm-svn: 214747
-
Bill Wendling authored
```--------------------------------------------------------------------- r214119 | joerg | 2014-07-28 14:06:22 -0700 (Mon, 28 Jul 2014) | 7 lines Change __INTx_TYPE__ to be always signed. This changes the value for char-based types from "char" to "signed char". Adjust stdint.h to use __INTx_TYPE__ directly without prefixing it with signed and to use __UINTx_TYPE__ for unsigned ones. The value of __INTx_TYPE__ now matches GCC. ``` --------------------------------------------------------------------- llvm-svn: 214746
-
Bill Wendling authored
```--------------------------------------------------------------------- r214222 | rsmith | 2014-07-29 14:20:12 -0700 (Tue, 29 Jul 2014) | 4 lines PR20473: Don't "deduplicate" string literals with the same value but different lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. ``` --------------------------------------------------------------------- llvm-svn: 214745
-
Bill Wendling authored
llvm-svn: 214744
-
Bill Wendling authored
```--------------------------------------------------------------------- r214369 | rsmith | 2014-07-30 17:22:56 -0700 (Wed, 30 Jul 2014) | 2 lines Rename this test so that it actually runs, and fix it so that it passes. ``` --------------------------------------------------------------------- llvm-svn: 214743
-
Bill Wendling authored
```--------------------------------------------------------------------- r214050 | rsmith | 2014-07-26 22:12:49 -0700 (Sat, 26 Jul 2014) | 7 lines When looking for temporary dtors while building the CFG, do not walk into lambda expressions (other than their capture initializers) nor blocks. Do walk into default argument expressions and default initializer expressions. These bugs were causing us to produce broken CFGs whenever a lambda expression was used to initialize a libstdc++ std::function object! ``` --------------------------------------------------------------------- llvm-svn: 214742
-
Bill Wendling authored
```--------------------------------------------------------------------- r214471 | rtrieu | 2014-07-31 18:42:01 -0700 (Thu, 31 Jul 2014) | 5 lines Remove this pointer that is converted to bool. In well-defined contexts, the this pointer is always non-null. If the this pointer is null, it is undefined and the compiler may optimize it away by assuming it is non-null. The null checks are pushed into the callers. ``` --------------------------------------------------------------------- llvm-svn: 214741
-
Bill Wendling authored
```--------------------------------------------------------------------- r214008 | rtrieu | 2014-07-25 19:10:52 -0700 (Fri, 25 Jul 2014) | 3 lines If a template argument is non-evaluable expression, use the profile ID to see if the two arguments are equal. ``` --------------------------------------------------------------------- llvm-svn: 214696
-
Bill Wendling authored
```--------------------------------------------------------------------- r213912 | rtrieu | 2014-07-24 17:24:02 -0700 (Thu, 24 Jul 2014) | 4 lines Pass the PrintingPolicy when converting types to strings in template type diffing. This removes extra "struct"/"class" in the type names and gives "bool" instead of "_Bool" for booleans. ``` --------------------------------------------------------------------- llvm-svn: 214695
-
Bill Wendling authored
```--------------------------------------------------------------------- r213902 | rtrieu | 2014-07-24 16:14:16 -0700 (Thu, 24 Jul 2014) | 3 lines Print "(default)" for default template template arguments to match the printing of other types. ``` --------------------------------------------------------------------- llvm-svn: 214694
-
Bill Wendling authored
```--------------------------------------------------------------------- r213840 | rtrieu | 2014-07-23 21:24:50 -0700 (Wed, 23 Jul 2014) | 2 lines Add support for nullptr template arguments to template type diffing. ``` --------------------------------------------------------------------- llvm-svn: 214693
-
Bill Wendling authored
```--------------------------------------------------------------------- r213613 | rtrieu | 2014-07-21 21:42:15 -0700 (Mon, 21 Jul 2014) | 2 lines Fix '&' printing for template arguments in parentheses in template diffing. ``` --------------------------------------------------------------------- llvm-svn: 214692
-
Bill Wendling authored
```--------------------------------------------------------------------- r213611 | rtrieu | 2014-07-21 21:06:54 -0700 (Mon, 21 Jul 2014) | 2 lines More gracefully handle parentheses in templare arguments in template diffing. ``` --------------------------------------------------------------------- llvm-svn: 214691
-
Bill Wendling authored
```--------------------------------------------------------------------- r213609 | rtrieu | 2014-07-21 20:33:01 -0700 (Mon, 21 Jul 2014) | 3 lines Fix a template diffing problem were an '&' is unexpectedly printed in a template argument. ``` --------------------------------------------------------------------- llvm-svn: 214690
-
Bill Wendling authored
```--------------------------------------------------------------------- r213665 | tnorthover | 2014-07-22 08:47:09 -0700 (Tue, 22 Jul 2014) | 11 lines X86: drop relocations on __eh_frame sections globally. Without this, we produce non-extern relocations when targeting older OS X versions that ld64 can't cope with in the particular context of __eh_frame sections (who'd want generic relocation-processing anyway?). This means that an updated linker (ld64 from Xcode 3.2.6 or later) may be needed when targeting such platforms with a modern version of LLVM, but this is probably the case anyway and a reasonable requirement. PR20212, rdar://problem/17544795 ``` --------------------------------------------------------------------- llvm-svn: 214689
-