Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Aug 16, 2013
  3. Aug 15, 2013
  5. Aug 01, 2013
    • Tim Northover's avatar
      AArch64: initial NEON support · b793f0d3
      Tim Northover authored 
      Patch by Ana Pazos

- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise

- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic

- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same

- Intial implementation of instruction class:
Scalar Arithmetic

- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.

- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187568 91177308-0d34-0410-b5e6-96231b3b80d8
      b793f0d3
  7. Jul 31, 2013
  9. Jul 30, 2013
  11. Jul 22, 2013
  13. Jul 19, 2013
  15. Jun 24, 2013
  17. Jun 18, 2013
  19. Jun 10, 2013
  21. May 31, 2013
  23. May 25, 2013
  25. May 15, 2013
    • Jim Grosbach's avatar
      ARM: Improve codegen for vget_low_* and vget_high_ intrinsics. · cd765392
      Jim Grosbach authored 
      These intrinsics use the __builtin_shuffle() function to extract the
low and high half, respectively, of a 128-bit NEON vector. Currently,
they're defined to use bitcasts to simplify the emitter, so we get code
like:
uint16x4_t vget_low_u32(uint16x8_t __a) {
  return (uint32x2_t) __builtin_shufflevector((int64x2_t) __a,
                                              (int64x2_t) __a,
                                              0);
}

While this works, it results in those bitcasts going all the way through
to the IR, resulting in code like:
  %1 = bitcast <8 x i16> %in to <2 x i64>
  %2 = shufflevector <2 x i64> %1, <2 x i64> undef, <1 x i32>
  %zeroinitializer
  %3 = bitcast <1 x i64> %2 to <4 x i16>

We can instead easily perform the operation directly on the input vector
like:

uint16x4_t vget_low_u16(uint16x8_t __a) {
  return __builtin_shufflevector(__a, __a, 0, 1, 2, 3);
}

Not only is that much easier to read on its own, it also results in
cleaner IR like:

  %1 = shufflevector <8 x i16> %in, <8 x i16> undef,
                     <4 x i32> <i32 0, i32 1, i32 2, i32 3>

This is both easier to read and easier for the back end to reason
about effectively since the operation is obfuscating the source with
bitcasts.

rdar://13894163

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181865 91177308-0d34-0410-b5e6-96231b3b80d8
      cd765392
  27. May 14, 2013
  29. May 05, 2013
  31. May 03, 2013
    • Douglas Gregor's avatar
      Restore Richard's belief in me. · 4761b102
      Douglas Gregor authored 
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181042 91177308-0d34-0410-b5e6-96231b3b80d8
      4761b102
    • Douglas Gregor's avatar
      Use attribute argument information to determine when to parse attribute arguments as expressions. · 92eb7d84
      Douglas Gregor authored 
      This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align((Align)))) char storage[Size];
 };

while this would parse as a "parameter name" 'Align':

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align(Align))) char storage[Size];
 };

The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align)) char storage[Size];
 };

i.e., use the maximal alignment rather than the specified alignment.

Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.

Fixes <rdar://problem/13700933>.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180973 91177308-0d34-0410-b5e6-96231b3b80d8
      92eb7d84
    • Douglas Gregor's avatar
      Revert r180970; it's causing breakage. · fa5f0305
      Douglas Gregor authored 
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180972 91177308-0d34-0410-b5e6-96231b3b80d8
      fa5f0305
    • Douglas Gregor's avatar
      Use attribute argument information to determine when to parse attribute arguments as expressions. · 3796d153
      Douglas Gregor authored 
      This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":

  template<unsigned Size, unsigned Align>
  class my_aligned_storage
  {
    __attribute__((align((Align)))) char storage[Size];
  };

while this would parse as a "parameter name" 'Align':

  template<unsigned Size, unsigned Align>
  class my_aligned_storage
  {
    __attribute__((align(Align))) char storage[Size];
  };

The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to

  template<unsigned Size, unsigned Align>
  class my_aligned_storage
  {
    __attribute__((align)) char storage[Size];
  };

i.e., use the maximal alignment rather than the specified alignment.

Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.

Fixes <rdar://problem/13700933>.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180970 91177308-0d34-0410-b5e6-96231b3b80d8
      3796d153
  33. Apr 25, 2013
  35. Apr 17, 2013
  37. Apr 16, 2013
  39. Apr 12, 2013
  41. Apr 05, 2013
  43. Apr 02, 2013
  45. Mar 26, 2013
  47. Mar 25, 2013
  49. Mar 23, 2013
  51. Mar 09, 2013
  53. Mar 08, 2013
  55. Mar 05, 2013
  57. Feb 21, 2013
  59. Feb 01, 2013