Commit Graph

15 Commits

Author SHA1 Message Date
Reid Kleckner 38e033bf33 Re-land Remove REQUIRES:shell from tests that pass for me on Windows
This reverts r371497 (git commit 3d7e9ab7b9)

Reorder `not` with `env` in these two tests so they pass:
  Driver/rewrite-map-in-diagnostics.c
  Index/crash-recovery-modules.m.

This will not be necessary after D66531 lands.

llvm-svn: 371552
2019-09-10 20:15:45 +00:00
James Henderson 3d7e9ab7b9 Revert Remove REQUIRES:shell from tests that pass for me on Windows
This reverts r371478 (git commit a9980f60ce)

llvm-svn: 371497
2019-09-10 08:48:33 +00:00
Reid Kleckner a9980f60ce Remove REQUIRES:shell from tests that pass for me on Windows
I see in the history for some of these tests REQUIRES:shell was used as
a way to disable tests on Windows because they are flaky there. I tried
not to re-enable such tests, but it's possible that I missed some and
this will re-enable flaky tests on Windows. If so, we should disable
them with UNSUPPORTED:system-windows and add a comment that they are
flaky there. So far as I can tell, the lit internal shell is capable of
running all of these tests, and we shouldn't use REQUIRES:shell as a
proxy for Windows.

llvm-svn: 371478
2019-09-10 00:50:32 +00:00
Tim Northover a009a60a91 IR: print value numbers for unnamed function arguments
For consistency with normal instructions and clarity when reading IR,
it's best to print the %0, %1, ... names of function arguments in
definitions.

Also modifies the parser to accept IR in that form for obvious reasons.

llvm-svn: 367755
2019-08-03 14:28:34 +00:00
Alexey Bataev ac6e4de714 Do not always request an implicit taskgroup region inside the kmpc_taskloop function
Summary:
For the following code:
```
    int i;
    #pragma omp taskloop
    for (i = 0; i < 100; ++i)
    {}

    #pragma omp taskloop nogroup
    for (i = 0; i < 100; ++i)
    {}
```

Clang emits the following LLVM IR:

```
 ...
  call void @__kmpc_taskgroup(%struct.ident_t* @0, i32 %0)
  %2 = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* @0, i32 %0, i32 1, i64 80, i64 8, i32 (i32, i8*)* bitcast (i32 (i32, %struct.kmp_task_t_with_privates*)* @.omp_task_entry. to i32 (i32, i8*)*))
  ...
  call void @__kmpc_taskloop(%struct.ident_t* @0, i32 %0, i8* %2, i32 1, i64* %8, i64* %9, i64 %13, i32 0, i32 0, i64 0, i8* null)
  call void @__kmpc_end_taskgroup(%struct.ident_t* @0, i32 %0)

  ...
  %15 = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* @0, i32 %0, i32 1, i64 80, i64 8, i32 (i32, i8*)* bitcast (i32 (i32, %struct.kmp_task_t_with_privates.1*)* @.omp_task_entry..2 to i32 (i32, i8*)*))
  ...
  call void @__kmpc_taskloop(%struct.ident_t* @0, i32 %0, i8* %15, i32 1, i64* %21, i64* %22, i64 %26, i32 0, i32 0, i64 0, i8* null)

```

The first set of instructions corresponds to the first taskloop construct. It is important to note that the implicit taskgroup region associated with the taskloop construct has been materialized in our IR:  the `__kmpc_taskloop` occurs inside a taskgroup region. Note also that this taskgroup region does not exist in our second taskloop because we are using the `nogroup` clause.

The issue here is the 4th argument of the kmpc_taskloop call, starting from the end,  is always a zero. Checking the LLVM OpenMP RT implementation, we see that this argument corresponds to the nogroup parameter:

```
void __kmpc_taskloop(ident_t *loc, int gtid, kmp_task_t *task, int if_val,
                     kmp_uint64 *lb, kmp_uint64 *ub, kmp_int64 st, int nogroup,
                     int sched, kmp_uint64 grainsize, void *task_dup);
```

So basically we always tell to the RT to do another taskgroup region. For the first taskloop, this means that we create two taskgroup regions. For the second example, it means that despite the fact we had a nogroup clause we are going to have a taskgroup region, so we unnecessary wait until all descendant tasks have been executed.

Reviewers: ABataev

Reviewed By: ABataev

Subscribers: rogfer01, cfe-commits

Differential Revision: https://reviews.llvm.org/D53636

llvm-svn: 345180
2018-10-24 19:06:37 +00:00
Sean Fertile d900dd0c23 Revert "[CodeGenCXX] Treat 'this' as noalias in constructors"
This reverts commit https://reviews.llvm.org/rL344150 which causes
MachineOutliner related failures on the ppc64le multistage buildbot.

llvm-svn: 344526
2018-10-15 15:43:00 +00:00
Anton Bikineev cc7e74753a [CodeGenCXX] Treat 'this' as noalias in constructors
This is currently a clang extension and a resolution
of the defect report in the C++ Standard.

Differential Revision: https://reviews.llvm.org/D46441

llvm-svn: 344150
2018-10-10 16:14:51 +00:00
Alexey Bataev a8a9153a37 [OPENMP] Support for -fopenmp-simd option with compilation of simd loops
only.

Added support for -fopenmp-simd option that allows compilation of
simd-based constructs without emission of OpenMP runtime calls.

llvm-svn: 321560
2017-12-29 18:07:07 +00:00
Alexey Bataev be5a8b42cd [OPENMP] Codegen for reduction clauses in 'taskloop' directives.
Adds codegen for taskloop-based directives.

llvm-svn: 308174
2017-07-17 13:30:36 +00:00
Reid Kleckner 7a2037151c Remove unnecessary x86 backend requirements from OpenMP tests
Clang can generate LLVM IR for x86 without a registered x86 backend.

llvm-svn: 284836
2016-10-21 16:09:20 +00:00
Reid Kleckner 5f8878fa5e Revert 9 changes from r284793, they still fail on some bots
llvm-svn: 284794
2016-10-20 23:30:39 +00:00
Reid Kleckner 2e1538f282 Remove 24 instances of 'REQUIRES: shell'
Tests fall into one of the following categories:

- The requirement was unnecessary

- Additional quoting was required for backslashes in paths (see "sed -e
  's/\\/\\\\/g'") in the sanitizer tests.

- OpenMP used 'REQUIRES: shell' as a proxy for the test failing on
  Windows. Those tests fail there reliably, so use XFAIL instead.

I tried not to remove shell requirements that were added to suppress
flaky test failures, but if I screwed up, we can add it back as needed.

llvm-svn: 284793
2016-10-20 23:11:45 +00:00
Alexey Bataev ad537bb8a0 [OPENMP 4.5] Fixed codegen for 'priority' and destructors in task-based
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).

llvm-svn: 271201
2016-05-30 09:06:50 +00:00
Alexey Bataev 8a83159731 [OPENMP 4.0] Fixed codegen for destructors in task-based directives.
If private variables require destructors call at the deletion of the
task, additional flag in task flags must be set. Patch fixes this
problem.

llvm-svn: 269039
2016-05-10 10:36:51 +00:00
Alexey Bataev a139f86128 [OPENMP 4.5] Tests for 'private|firstprivates' clauses in 'taskloop' directive.
Added tests for codegen for private|firstprivate clauses in taskloop-based directives.

llvm-svn: 268729
2016-05-06 12:04:14 +00:00