Skip to content
Snippets Groups Projects
  1. May 07, 2017
  2. Apr 18, 2017
  3. Apr 13, 2017
  4. Apr 05, 2017
  5. Apr 04, 2017
    • Adam Nemet's avatar
      Add #pragma clang fp · 6abfe5cf
      Adam Nemet authored
      This adds the new pragma and the first variant, contract(on/off/fast).
      
      The pragma has the same block scope rules as STDC FP_CONTRACT, i.e. it can be
      placed at the beginning of a compound statement or at file scope.
      
      Similarly to STDC FP_CONTRACT there is no need to use attributes.  First an
      annotate token is inserted with the parsed details of the pragma.  Then the
      annotate token is parsed in the proper contexts and the Sema is updated with
      the corresponding FPOptions using the shared ActOn function with STDC
      FP_CONTRACT.
      
      After this the FPOptions from the Sema is propagated into the AST expression
      nodes.  There is no change here.
      
      I was going to add a 'default' option besides 'on/off/fast' similar to STDC
      FP_CONTRACT but then decided against it. I think that we'd have to make option
      uppercase then to avoid using 'default' the keyword.  Also because of the
      scoped activation of pragma I am not sure there is really a need a for this.
      
      Differential Revision: https://reviews.llvm.org/D31276
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299470 91177308-0d34-0410-b5e6-96231b3b80d8
      6abfe5cf
  6. Mar 21, 2017
  7. Jan 23, 2017
  8. Jan 20, 2017
  9. Oct 04, 2016
  10. Jun 21, 2016
  11. Jun 14, 2016
    • Adam Nemet's avatar
      Fix documentation bot after r272656 · 699ee8e7
      Adam Nemet authored
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272699 91177308-0d34-0410-b5e6-96231b3b80d8
      699ee8e7
    • Adam Nemet's avatar
      Add loop pragma for Loop Distribution · e280490a
      Adam Nemet authored
      Summary:
      This is similar to other loop pragmas like 'vectorize'.  Currently it
      only has state values: distribute(enable) and distribute(disable).  When
      one of these is specified the corresponding loop metadata is generated:
      
        !{!"llvm.loop.distribute.enable", i1 true/false}
      
      As a result, loop distribution will be attempted on the loop even if
      Loop Distribution in not enabled globally.  Analogously, with 'disable'
      distribution can be turned off for an individual loop even when the pass
      is otherwise enabled.
      
      There are some slight differences compared to the existing loop pragmas.
      
      1. There is no 'assume_safety' variant which makes its handling slightly
      different from 'vectorize'/'interleave'.
      
      2. Unlike the existing loop pragmas, it does not have a corresponding
      numeric pragma like 'vectorize' -> 'vectorize_width'.  So for the
      consistency checks in CheckForIncompatibleAttributes we don't need to
      check it against other pragmas.  We just need to check for duplicates of
      the same pragma.
      
      Reviewers: rsmith, dexonsmith, aaron.ballman
      
      Subscribers: bob.wilson, cfe-commits, hfinkel
      
      Differential Revision: http://reviews.llvm.org/D19403
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272656 91177308-0d34-0410-b5e6-96231b3b80d8
      e280490a
  12. May 23, 2016
    • David Majnemer's avatar
      Clang support for __is_assignable intrinsic · d1cedd4e
      David Majnemer authored
      MSVC now supports the __is_assignable type trait intrinsic,
      to enable easier and more efficient implementation of the
      Standard Library's is_assignable trait.
      As of Visual Studio 2015 Update 3, the VC Standard Library
      implementation uses the new intrinsic unconditionally.
      
      The implementation is pretty straightforward due to the previously
      existing is_nothrow_assignable and is_trivially_assignable.
      We handle __is_assignable via the same code as the other two except
      that we skip the extra checks for nothrow or triviality.
      
      Patch by Dave Bartolomeo!
      
      Differential Revision: http://reviews.llvm.org/D20492
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270458 91177308-0d34-0410-b5e6-96231b3b80d8
      d1cedd4e
  13. May 03, 2016
  14. Mar 24, 2016
  15. Mar 23, 2016
  16. Feb 27, 2016
  17. Feb 14, 2016
  18. Nov 14, 2015
  19. Oct 29, 2015
  20. Sep 11, 2015
  21. Sep 02, 2015
  22. Aug 10, 2015
    • Nick Lewycky's avatar
      Fix typo. · 1525c826
      Nick Lewycky authored
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244490 91177308-0d34-0410-b5e6-96231b3b80d8
      1525c826
    • Mark Heffernan's avatar
      Add new llvm.loop.unroll.enable metadata for use with "#pragma unroll". · 1476822d
      Mark Heffernan authored
      This change adds the new unroll metadata "llvm.loop.unroll.enable" which directs
      the optimizer to unroll a loop fully if the trip count is known at compile time, and
      unroll partially if the trip count is not known at compile time. This differs from
      "llvm.loop.unroll.full" which explicitly does not unroll a loop if the trip count is not
      known at compile time
      
      With this change "#pragma unroll" generates "llvm.loop.unroll.enable" rather than
      "llvm.loop.unroll.full" metadata. This changes the semantics of "#pragma unroll" slightly
      to mean "unroll aggressively (fully or partially)" rather than "unroll fully or not at all".
      
      The motivating example for this change was some internal code with a loop marked
      with "#pragma unroll" which only sometimes had a compile-time trip count depending
      on template magic. When the trip count was a compile-time constant, everything works
      as expected and the loop is fully unrolled. However, when the trip count was not a
      compile-time constant the "#pragma unroll" explicitly disabled unrolling of the loop(!).
      Removing "#pragma unroll" caused the loop to be unrolled partially which was desirable
      from a performance perspective.
      
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244467 91177308-0d34-0410-b5e6-96231b3b80d8
      1476822d
  23. Aug 05, 2015
  24. Jul 13, 2015
  25. Jun 15, 2015
    • Peter Collingbourne's avatar
      Protection against stack-based memory corruption errors using SafeStack: Clang... · 4d2986d8
      Peter Collingbourne authored
      Protection against stack-based memory corruption errors using SafeStack: Clang command line option and function attribute
      
      This patch adds the -fsanitize=safe-stack command line argument for clang,
      which enables the Safe Stack protection (see http://reviews.llvm.org/D6094
      for the detailed description of the Safe Stack).
      
      This patch is our implementation of the safe stack on top of Clang. The
      patches make the following changes:
      
      - Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang
        to control safe stack usage (the safe stack is disabled by default).
      
      - Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be
        used to disable the safe stack for individual functions even when enabled
        globally.
      
      Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
      Lab at EPFL; updates and upstreaming by myself.
      
      Differential Revision: http://reviews.llvm.org/D6095
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239762 91177308-0d34-0410-b5e6-96231b3b80d8
      4d2986d8
  26. Mar 10, 2015
  27. Dec 05, 2014
  28. Dec 03, 2014
  29. Nov 14, 2014
  30. Nov 12, 2014
  31. Oct 10, 2014
Loading