1. 24 Feb, 2017 3 commits
  2. 23 Feb, 2017 1 commit
    • Hans Wennborg's avatar
      Merging r295473: · ad64489d
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r295473 | hahnfeld | 2017-02-17 10:32:51 -0800 (Fri, 17 Feb 2017) | 13 lines
      
      [OpenMP] Remove barriers at cancel and cancellation point
      
      This resolves a deadlock with the cancel directive when there is no explicit
      cancellation point. In that case, the implicit barrier acts as cancellation
      point. After removing the barrier after cancel, the now unmatched barrier for
      the explicit cancellation point has to go as well.
      
      This has probably worked before rL255992: With the calls for the explicit
      barrier, it was sure that all threads passed a barrier before exiting.
      
      Reported by Simon Convent and Joachim Protze!
      
      Differential Revision: https://reviews.llvm.org/D30088
      ------------------------------------------------------------------------
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_40@296000 91177308-0d34-0410-b5e6-96231b3b80d8
      ad64489d
  3. 10 Jan, 2017 1 commit
  4. 05 Jan, 2017 1 commit
  5. 23 Dec, 2016 1 commit
    • Chandler Carruth's avatar
      Cleanup the handling of noinline function attributes, -fno-inline, · d0ca1639
      Chandler Carruth authored
      -fno-inline-functions, -O0, and optnone.
      
      These were really, really tangled together:
      - We used the noinline LLVM attribute for -fno-inline
        - But not for -fno-inline-functions (breaking LTO)
        - But we did use it for -finline-hint-functions (yay, LTO is happy!)
        - But we didn't for -O0 (LTO is sad yet again...)
      - We had weird structuring of CodeGenOpts with both an inlining
        enumeration and a boolean. They interacted in weird ways and
        needlessly.
      - A *lot* of set smashing went on with setting these, and then got worse
        when we considered optnone and other inlining-effecting attributes.
      - A bunch of inline affecting attributes were managed in a completely
        different place from -fno-inline.
      - Even with -fno-inline we failed to put the LLVM noinline attribute
        onto many generated function definitions because they didn't show up
        as AST-level functions.
      - If you passed -O0 but -finline-functions we would run the normal
        inliner pass in LLVM despite it being in the O0 pipeline, which really
        doesn't make much sense.
      - Lastly, we used things like '-fno-inline' to manipulate the pass
        pipeline which forced the pass pipeline to be much more
        parameterizable than it really needs to be. Instead we can *just* use
        the optimization level to select a pipeline and control the rest via
        attributes.
      
      Sadly, this causes a bunch of churn in tests because we don't run the
      optimizer in the tests and check the contents of attribute sets. It
      would be awesome if attribute sets were a bit more FileCheck friendly,
      but oh well.
      
      I think this is a significant improvement and should remove the semantic
      need to change what inliner pass we run in order to comply with the
      requested inlining semantics by relying completely on attributes. It
      also cleans up tho optnone and related handling a bit.
      
      One unfortunate aspect of this is that for generating alwaysinline
      routines like those in OpenMP we end up removing noinline and then
      adding alwaysinline. I tried a bunch of other approaches, but because we
      recompute function attributes from scratch and don't have a declaration
      here I couldn't find anything substantially cleaner than this.
      
      Differential Revision: https://reviews.llvm.org/D28053
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290398 91177308-0d34-0410-b5e6-96231b3b80d8
      d0ca1639
  6. 12 Dec, 2016 2 commits
  7. 28 Nov, 2016 2 commits
  8. 24 Nov, 2016 1 commit
  9. 19 Nov, 2016 1 commit
  10. 13 Nov, 2016 1 commit
  11. 11 Nov, 2016 1 commit
  12. 01 Aug, 2016 1 commit
  13. 30 Jul, 2016 1 commit
  14. 29 Jul, 2016 1 commit
  15. 28 Jul, 2016 4 commits
  16. 27 Jul, 2016 2 commits
  17. 24 Jun, 2016 1 commit
  18. 16 Jun, 2016 3 commits
  19. 14 Jun, 2016 1 commit
  20. 10 Jun, 2016 1 commit
  21. 30 May, 2016 2 commits
    • Alexey Bataev's avatar
      [OPENMP 4.5] Additional codegen for statically scheduled loops with · 37ac732d
      Alexey Bataev authored
      'simd' modifier.
      
      Runtime library defines new schedule constant kmp_sch_static_balanced_chunked = 45 for static loop-based directives  static with chunk adjustment (e.g., simd). Added codegen for this kind of schedule.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271204 91177308-0d34-0410-b5e6-96231b3b80d8
      37ac732d
    • Alexey Bataev's avatar
      [OPENMP 4.5] Fixed codegen for 'priority' and destructors in task-based · 60f07699
      Alexey Bataev authored
      directives.
      
      'kmp_task_t' record type added a new field for 'priority' clause and
      changed the representation of pointer to destructors for privates used
      within loop-based directives.
      Old representation:
      
      typedef struct kmp_task {                   /* GEH: Shouldn't this be
      aligned somehow? */
        void *shareds;                            /**< pointer to block of
          pointers to shared vars   */
        kmp_routine_entry_t routine;              /**< pointer to routine
          to call for executing task */
        kmp_int32 part_id;                        /**< part id for the
          task                          */
        kmp_routine_entry_t destructors;        /* pointer to function to
        invoke deconstructors of firstprivate C++ objects */
        /*  private vars  */
      } kmp_task_t;
      
      New representation:
      
      typedef struct kmp_task {                   /* GEH: Shouldn't this be
      aligned somehow? */
        void *shareds;                            /**< pointer to block of
          pointers to shared vars   */
        kmp_routine_entry_t routine;              /**< pointer to routine
          to call for executing task */
        kmp_int32 part_id;                        /**< part id for the
          task                          */
        kmp_cmplrdata_t data1; /* Two known
      optional additions: destructors and priority */
        kmp_cmplrdata_t data2; /* Process
      destructors first, priority second */
      /* future data */
        /*  private vars  */
      } kmp_task_t;
      
      Also excessive initialization of 'destructors' fields to 'null' was
      removed from codegen if it is known that no destructors shal be used.
      Currently a special bit is used in 'kmp_tasking_flags_t' bitfields
      ('destructors_thunk' bitfield).
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271201 91177308-0d34-0410-b5e6-96231b3b80d8
      60f07699
  22. 26 May, 2016 3 commits
  23. 25 May, 2016 1 commit
  24. 17 May, 2016 1 commit
  25. 10 May, 2016 3 commits