Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
  • Dr. Jorrit Fahlke Dr. Jorrit Fahlke jfahl_01
  • Jan Hönig hoenig
  • Marcel Dominique Koch marckoch
  • Martin Bauer bauermar
  • Michael Haidl m_haid02
  • Prof. Dr. Christian Engwer Prof. Dr. Christian Engwer cengw_01
  • René Heß hessr
  • Vladyslav Kucher kucher
8 authors
  1. Jul 22, 2016
  3. Jul 21, 2016
  5. Jul 14, 2016
  7. Jul 12, 2016
  9. Jul 06, 2016
  11. Jul 05, 2016
  13. Jun 27, 2016
    • Carlo Bertolli's avatar
      Resubmission of http://reviews.llvm.org/D21564 after fixes. · 012ef212
      Carlo Bertolli authored 
      [OpenMP] Initial implementation of parse and sema for composite pragma 'distribute parallel for'

This patch is an initial implementation for #distribute parallel for.
The main differences that affect other pragmas are:

The implementation of 'distribute parallel for' requires blocking of the associated loop, where blocks are "distributed" to different teams and iterations within each block are scheduled to parallel threads within each team. To implement blocking, sema creates two additional worksharing directive fields that are used to pass the team assigned block lower and upper bounds through the outlined function resulting from 'parallel'. In this way, scheduling for 'for' to threads can use those bounds.
As a consequence of blocking, the stride of 'distribute' is not 1 but it is equal to the blocking size. This is returned by the runtime and sema prepares a DistIncrExpr variable to hold that value.
As a consequence of blocking, the global upper bound (EnsureUpperBound) expression of the 'for' is not the original loop upper bound (e.g. in for(i = 0 ; i < N; i++) this is 'N') but it is the team-assigned block upper bound. Sema creates a new expression holding the calculation of the actual upper bound for 'for' as UB = min(UB, PrevUB), where UB is the loop upper bound, and PrevUB is the team-assigned block upper bound.




git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273884 91177308-0d34-0410-b5e6-96231b3b80d8
      012ef212
  15. Jun 24, 2016
    • Carlo Bertolli's avatar
      Revert r273705 · 912e4df3
      Carlo Bertolli authored 
       [OpenMP] Initial implementation of parse and sema for composite pragma 'distribute parallel for'




git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273709 91177308-0d34-0410-b5e6-96231b3b80d8
      912e4df3
    • Carlo Bertolli's avatar
      [OpenMP] Initial implementation of parse and sema for composite pragma 'distribute parallel for' · 396e7147
      Carlo Bertolli authored 
      http://reviews.llvm.org/D21564

This patch is an initial implementation for #distribute parallel for.
The main differences that affect other pragmas are:

The implementation of 'distribute parallel for' requires blocking of the associated loop, where blocks are "distributed" to different teams and iterations within each block are scheduled to parallel threads within each team. To implement blocking, sema creates two additional worksharing directive fields that are used to pass the team assigned block lower and upper bounds through the outlined function resulting from 'parallel'. In this way, scheduling for 'for' to threads can use those bounds.
As a consequence of blocking, the stride of 'distribute' is not 1 but it is equal to the blocking size. This is returned by the runtime and sema prepares a DistIncrExpr variable to hold that value.
As a consequence of blocking, the global upper bound (EnsureUpperBound) expression of the 'for' is not the original loop upper bound (e.g. in for(i = 0 ; i < N; i++) this is 'N') but it is the team-assigned block upper bound. Sema creates a new expression holding the calculation of the actual upper bound for 'for' as UB = min(UB, PrevUB), where UB is the loop upper bound, and PrevUB is the team-assigned block upper bound.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273705 91177308-0d34-0410-b5e6-96231b3b80d8
      396e7147
  17. Jun 23, 2016
  19. Jun 15, 2016
  21. May 31, 2016
  23. May 26, 2016
  25. May 25, 2016
    • Hal Finkel's avatar
      Add a loop's debug location to its llvm.loop metadata · 04ad5509
      Hal Finkel authored 
      Getting accurate locations for loops is important, because those locations are
used by the frontend to generate optimization remarks. Currently, optimization
remarks for loops often appear on the wrong line, often the first line of the
loop body instead of the loop itself. This is confusing because that line might
itself be another loop, or might be somewhere else completely if the body was
an inlined function call. This happens because of the way we find the loop's
starting location. First, we look for a preheader, and if we find one, and its
terminator has a debug location, then we use that. Otherwise, we look for a
location on an instruction in the loop header.

The fallback heuristic is not bad, but will almost always find the beginning of
the body, and not the loop statement itself. The preheader location search
often fails because there's often not a preheader, and even when there is a
preheader, depending on how it was formed, it sometimes carries the location of
some preceeding code.

I don't see any good theoretical way to fix this problem. On the other hand,
this seems like a straightforward solution: Put the debug location in the
loop's llvm.loop metadata. When emitting debug information, this commit causes
us to add the debug location as an operand to each loop's llvm.loop metadata.
Thus, we now generate this metadata for all loops (not just loops with
optimization hints) when we're otherwise generating debug information.

The remark test case changes depend on the companion LLVM commit r270771.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270772 91177308-0d34-0410-b5e6-96231b3b80d8
      04ad5509
  27. Apr 19, 2016
  29. Mar 20, 2016
  31. Mar 11, 2016
  33. Feb 04, 2016
  35. Feb 03, 2016
  37. Jan 28, 2016
  39. Jan 26, 2016
  41. Jan 19, 2016
  43. Dec 15, 2015
  45. Dec 14, 2015
  47. Dec 10, 2015
  49. Dec 09, 2015
  51. Dec 08, 2015
  53. Dec 06, 2015
  55. Dec 03, 2015
  57. Dec 01, 2015
  59. Nov 07, 2015
  61. Oct 27, 2015
  63. Oct 21, 2015
  65. Sep 10, 2015
  67. Sep 08, 2015
    • John McCall's avatar
      Compute and preserve alignment more faithfully in IR-generation. · f4ddf94e
      John McCall authored 
      Introduce an Address type to bundle a pointer value with an
alignment.  Introduce APIs on CGBuilderTy to work with Address
values.  Change core APIs on CGF/CGM to traffic in Address where
appropriate.  Require alignments to be non-zero.  Update a ton
of code to compute and propagate alignment information.

As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.

The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned.  Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay.  I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.

Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.

We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment.  In particular,
field access now uses alignmentAtOffset instead of min.

Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs.  For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint.  That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.

ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments.  In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments.  That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.

I partially punted on applying this work to CGBuiltin.  Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246985 91177308-0d34-0410-b5e6-96231b3b80d8
      f4ddf94e
  69. Jul 27, 2015
    • Tyler Nowicki's avatar
      Use CGLoopInfo to emit metadata for loop hint pragmas. · 33ecde55
      Tyler Nowicki authored 
      When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata.

This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243315 91177308-0d34-0410-b5e6-96231b3b80d8
      33ecde55