This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP 5.0] Codegen support for user-defined mappers
ClosedPublic

Authored by lildmh on Mar 17 2019, 11:14 AM.

Details

Diff Detail

Repository
rL LLVM

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Combine 2 pointers into one.

lildmh marked 3 inline comments as done.Apr 26 2019, 10:36 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
2390 ↗(On Diff #191028)

The runtime part is on hold for now.

lib/CodeGen/CGOpenMPRuntime.h
351 ↗(On Diff #191028)

Yes, I plan to have this part in the next patch, which will implement to look up the corresponding mapper function for map. to, from clauses

ABataev added inline comments.Apr 26 2019, 12:54 PM
lib/CodeGen/CGOpenMPRuntime.cpp
8021 ↗(On Diff #196880)

This code has too many common parts with the existing one. Is it possible to merge it somehow or outline into a function?

8530 ↗(On Diff #196880)

Hmm, how could you calculate the required size of the array for the mapper? Or this is constant?

8588 ↗(On Diff #196880)

I think it would be good to move this part to the runtime. We should just pass the mapper function to the runtime functions and the runtime should call those mapper functions and get base pointers, pointers, sizes and maptypes.

8795 ↗(On Diff #196880)

With the buffering-based implementation we need only function.

lib/CodeGen/CGOpenMPRuntime.h
800 ↗(On Diff #196880)

I don't remember precisely, but probably \a->\p

804 ↗(On Diff #196880)

Use /// style of comment

351 ↗(On Diff #191028)

Noope, this must be the part of this patch, because it may cause the crash of the compiler during testing.

lildmh marked 7 inline comments as done.May 3 2019, 10:58 AM

Hi Alexey,

Again, thanks for your review! Sorry I didn't get back to you in time because I was distracted by other things. Please see the comments inline.

lib/CodeGen/CGOpenMPRuntime.cpp
8021 ↗(On Diff #196880)

I tried to merge it with generateAllInfo. The problem is generateAllInfo also generates information for clauses including to, from, is_device_ptr, use_device_ptr, which don't exist for declare mapper. There is no clear way to extract them separately. For example, every 4 or 5 lines, the code is intended to address a different clause type.
At last, I think the most clear way is to extract all code related to map clauses into this function generateAllInfoForMapper. It's ~70 lines of code so not too much.

8530 ↗(On Diff #196880)

I'm not sure I understand your question here.
Do you mean the size when an OpenMP array section is mapped? If that's the case, it is not constant. Existing code can already handle it.
Or do you mean the size of mapper array (i.e., MapArrayType)? This is constant and depends on how many map clauses exist in the declare mapper directive.

8588 ↗(On Diff #196880)

This part cannot be moved into the runtime, because the runtime does not know the map type associated with the mapper. Another argument can be potentially added to the runtime API, but that will be more work and I don't think it's necessary

8795 ↗(On Diff #196880)

Yes, in either case, we only generate functions here. Is there a problem?

lib/CodeGen/CGOpenMPRuntime.h
351 ↗(On Diff #191028)

It will not crash the compiler, because this UDMap is only written in this patch, never read.

lildmh updated this revision to Diff 198050.May 3 2019, 11:01 AM

Fix code format

ABataev added inline comments.May 3 2019, 11:47 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8021 ↗(On Diff #196880)

If those clauses do not exist for the declare mapper, it is fine, no problems with them. If they don't exist, we can't generate anything for them, no?
But if you think, that it would be better to extract some common parts into a separate function, this also works for me.

8530 ↗(On Diff #196880)

Yes, it is the question about the size of mapper array. It is the part of our discussion about mappers generation we had before. You said that it is hard to generate the sizes of the arrays since we don't know the number of map clauses at the codegen phase. bu there we have this number.

8588 ↗(On Diff #196880)

I think it is better again discuss the runtime part of the patch, because everything else depends on the runtime. I would suggest to try to implement the solution we discussed before, where the required data is stored in the runtime dynamic arrays and only after that it is used to transfer the data.

8795 ↗(On Diff #196880)

Sorry, I meant we'll need only one function.

lib/CodeGen/CGOpenMPRuntime.h
351 ↗(On Diff #191028)

Still, you should clear it in this patch. Otherwise, you're breaking data-dependency between the patches and this is not good at all.

lildmh marked 3 inline comments as done.May 3 2019, 12:16 PM

Hi Alexey,

Let's discuss your runtime data mapping scheme next week first. After that we will continue the review of this.

lib/CodeGen/CGOpenMPRuntime.cpp
8530 ↗(On Diff #196880)

Sorry there was probably some miscommunication. What I meant is that after fully expanded, for example, from map(mapper(id):a[0:n]), eventually to map(a.b.c[0:e]) map(a.k) ..., the number of things in the results is unknown at compile time.

Here, we only do one level of expansion of one instance based on the declare mapper directive, for example, the mapper is declare mapper(class A a) map(a.b[0:a.n]) map(a.c)
In this case, the size of mapper array is 2, because there are 2 map clauses (actually it's more than 2 because the first map clause maps an array). This number can be decided at compile time easily.

8795 ↗(On Diff #196880)

Yes, in that case, only one is needed.

lib/CodeGen/CGOpenMPRuntime.h
351 ↗(On Diff #191028)

Sure, if you think that's absolutely necessary, I can add it to this patch.

Hi Alexey,

Let's discuss your runtime data mapping scheme next week first. After that we will continue the review of this.

That would be good, thanks!

lib/CodeGen/CGOpenMPRuntime.cpp
8530 ↗(On Diff #196880)

Let's discuss the runtime at first, later we can return to this.

lib/CodeGen/CGOpenMPRuntime.h
351 ↗(On Diff #191028)

It is necessary, so, please, add it, thanks!

lildmh updated this revision to Diff 202790.Jun 3 2019, 1:55 PM
lildmh edited the summary of this revision. (Show Details)

Implement the new mapper codegen scheme

lildmh edited the summary of this revision. (Show Details)Jun 4 2019, 5:34 AM
lildmh updated this revision to Diff 202926.Jun 4 2019, 6:38 AM

Address Alexey's comment about mapping between function and user-defined mappers

lildmh updated this revision to Diff 203438.Jun 6 2019, 1:43 PM

Use tgt instead of kmpc for mapper runtime function names

ABataev added inline comments.Jun 10 2019, 8:48 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8729 ↗(On Diff #203438)

This function looks like the universal one, regardless of the type <type_name> specifics. Do we really need to generate it for each particular type and mapper? Or we could use the same function for all types/mappers?

lildmh marked an inline comment as done.Jun 10 2019, 9:18 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8729 ↗(On Diff #203438)

I think we need a particular mapper function for each type and mapper, because the code generated within the mapper function depends on what type and what mapper it is.

ABataev added inline comments.Jun 10 2019, 9:39 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8729 ↗(On Diff #203438)

Hmm, maybe I'm wrong but I don't see significant mapper or type-specific dependencies in this mapper function. It uses the pointer to type and size of the type, but this information can be generalized, I think. Could you point the lines of code that are type and mapper specific?

lildmh marked an inline comment as done.Jun 10 2019, 9:51 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8729 ↗(On Diff #203438)

Code between line 8857-8965 is type and mapper specific. For instance, generateAllInforForMapper depends on the map clauses associated with the mapper and the internal structure of struct/class type, and generates difference code as a result. BasePointers.size() also depends on the above things.

ABataev added inline comments.Jun 10 2019, 10:01 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8729 ↗(On Diff #203438)

Most of these data can be passed as parameters to the function. It would be good, if we could move this function to the libomptaret library and reduce the number of changes (and, thus, complexity) of the compiler itself. It is always easier to review and to maintain the source code written in C/C++ rather than the changes in the compiler codegen. Plus, it may reduce the size of the final code significantly, I assume. I would appreciate it if you would try to move this function to libomptarget.

8857 ↗(On Diff #203438)

These data can be passed as parameters to the function, no?

lildmh marked an inline comment as done.Jun 10 2019, 10:14 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8729 ↗(On Diff #203438)

Hi Alexey, I don't think libomptarget can do this efficiently. For example,

class C {
  int a;
  double *b
}

#pragma omp declare mapper(C c) map(c.a, c.b[0:1])

The codegen can directly know there are 2 components (c.a, c.b[0]) in this mapper function (3 actually when we count the pointer), and it can also know the size, starting address, map type, etc. about these components. Passing all these information to libomptarget seems to be a bad idea. Or did I get your idea wrong?

ABataev added inline comments.Jun 10 2019, 10:18 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8729 ↗(On Diff #203438)

Yes, I understand this. But can we pass some additional parameters to this function so we don't need to generate a unique copy of almost the same function for all types/mappers?

lildmh marked an inline comment as done.Jun 10 2019, 10:35 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8729 ↗(On Diff #203438)

For different types/mappers, the skeleton of mapper functions are similar (i.e., the things outlined in the comment here). I would say most other code is unique, for instance, the code to prepare parameters of call to __tgt_push_mapper_component. These code should be much more compared with the skeleton shown here. I cannot think of a way to reduce the code by passing more parameters to this function. Please let me know if you have some suggestions.

ABataev added inline comments.Jun 19 2019, 10:33 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Currently currentComponent is generated by the compiler. But can we instead pass this data as an extra parameter to this omp_mapper function.

8740 ↗(On Diff #203438)

I don't see this part of logic in the code. Could you show me where is it exactly?

8785 ↗(On Diff #203438)

Bad idea to do this. Better to use something like this:

SmallString<256> TyStr;
llvm::raw_svector_ostream Out(TyStr);
CGM.getCXXABI().getMangleContext().mangleTypeName(Ty, Out);
lildmh updated this revision to Diff 205647.Jun 19 2019, 11:22 AM
lildmh marked 3 inline comments as done.

Fix mapper function name mangling

lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Emm, I think this scheme will be very difficult and inefficient. If we pass components as an argument of omp_mapper function, it means that the runtime needs to generate all components related to a map clause. I don't think the runtime is able to do that efficiently. On the other hand, in the current scheme, these components are naturally generated by the compiler, and the runtime only needs to know the base pointer, pointer, type, size. etc.

8740 ↗(On Diff #203438)

This part doesn't exist in this patch. Currently we don't really look up the mapper for any mapped variable/array/etc. The next patch will add the code to look up the specified mapper for every map clause, and get the mapper function for them correspondingly.

8785 ↗(On Diff #203438)

Sounds good. Thanks!

ABataev added inline comments.Jun 19 2019, 11:56 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8773 ↗(On Diff #205647)

Always better to use constructor with the location to generate correct debug info for all the parameters.

8866–8867 ↗(On Diff #205647)

I don't like this code very much! It hides the logiс ща the MEMBER_OF flag deep inside and it is going to be very hard to update it in future if there are some changes in the flags.

8934 ↗(On Diff #205647)

I don't see this logic in the comment for the function. Could you add more details for all this logic implemented here?

8995 ↗(On Diff #205647)
  1. Use /// style of comment here
  2. Add the description of the logic implemented here
9003 ↗(On Diff #205647)

Use StringRef or SmallString

9020–9026 ↗(On Diff #205647)

Enclose all substatements into braces or none of them.

8739 ↗(On Diff #203438)

With the current scheme, we may end with the code blowout. We need to generate very similar code for different types and variables. The worst thing here is that we will be unable to optimize this huge amount of code because the codegen relies on the runtime functions and the code cannot be inlined. That's why I would like to move as much as possible code to the runtime rather than to emit it in the compiler.

8740 ↗(On Diff #203438)

Then we need at least some kind of TODO note that this part is not implemented in this patch.

lildmh updated this revision to Diff 205785.Jun 20 2019, 5:28 AM
lildmh marked 9 inline comments as done.

Address Alexey's comments

lib/CodeGen/CGOpenMPRuntime.cpp
8866–8867 ↗(On Diff #205647)

Add a function to calculate this offset. Also modify another existing place using the hard coded number 48.

8739 ↗(On Diff #203438)

I understand your concerns. I think this is the best we can do right now.

The most worrisome case will be when we have nested mappers within each other. In this case, a mapper function will call another mapper function. We can inline the inner mapper functions in this scenario, so that these mapper function can be properly optimized. As a result, I think the performance should be fine.

Sorry for the delay, Lingda. I tried to find some better solution for this.

lib/CodeGen/CGOpenMPRuntime.cpp
744 ↗(On Diff #205785)

Do we really need to use int64_t for number of elements? size_t must be enough.

8907 ↗(On Diff #205785)

You can use nuw attribute here, I think

9033 ↗(On Diff #205785)

You can use C.toBits(CGM.getSizeSize())

9055 ↗(On Diff #205785)

Just CGM.getSizeSize()

9056 ↗(On Diff #205785)

Add nuw attribute

8739 ↗(On Diff #203438)

Instead, we can use indirect function calls passed in the array to the runtime. Do you think it is going to be slower? In your current scheme, we generate many runtime calls instead. Could you try to estimate the number of calls in cases if we'll call the mappers through the indirect function calls and in your cuurent scheme, where we need to call the runtime functions many times in each particular mapper?

lildmh marked an inline comment as done.Jun 25 2019, 12:37 PM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Hi Alexey,

Sorry I don't understand your idea. What indirect function calls do you propose to be passed to the runtime? What are these functions supposed to do?

The number of function calls will be exactly equal to the number of components mapped, no matter whether there are nested mappers or not. The number of components depend on the program. E.g., if we map a large array section, then there will be many more function calls.

ABataev added inline comments.Jun 25 2019, 12:49 PM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

I mean the pointers to the mapper function, generated by the compiler. In your comment, it is c.Mapper()

lildmh marked 4 inline comments as done.Jun 25 2019, 1:02 PM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

If we pass nested mapper functions to the runtime, I think it will slow down execution because of the extra level of indirect function calls. E.g., the runtime will call omp_mapper1, which calls the runtime back, which calls omp_mapper2, .... This can result in a deep call stack.

I think the current implementation will be more efficient, which doesn't pass nested mappers to the runtime. One call to the outer most mapper function will have all data mapping done. The call stack will be 2 level deep (the first level is the mapper function, and the second level is __tgt_push_mapper_component) in this case from the runtime. There are also more compiler optimization space when we inline all nested mapper functions.

lildmh marked 2 inline comments as done.Jun 25 2019, 1:23 PM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
744 ↗(On Diff #205785)

Because we use the return value to shift the memberof filed of map type, which is int64_t, so I think int64_t makes sense here.

lildmh updated this revision to Diff 206527.Jun 25 2019, 1:52 PM
ABataev added inline comments.Jun 25 2019, 2:53 PM
lib/CodeGen/CGOpenMPRuntime.cpp
744 ↗(On Diff #205785)

Ok, there is a discrepancy between runtime part and compiler part: __tgt_push_mapper_component uses size_t for size, while the runtime function uses int64_t. It won't work for 32bit platform.

8739 ↗(On Diff #203438)

Yes, if we leave it as is. But if instead of the bunch unique functions we'll have the common one, that accept list if indirect pointers to functions additionally, and move it to the runtime library, we won't need those 2 functions we have currently. We'll have full access to the mapping data vector in the runtime library and won't need to use those 2 accessors we have currently. Instead, we'll need just one runtime functions, which implements the whole mapping logic. We still need to call it recursively, but I assume the number of calls will remain the same as in the current scheme. Did you understand the idea? If yes, it would good if you coild try to estimate the number of function calls in current scheme and in this new scheme to estimate possible pros and cons.

lildmh marked an inline comment as done.Jun 26 2019, 9:46 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Hi Alexey,

Could you give an example for this scheme? 1) I don't understand how the mapper function can have full access to the mapping data vector without providing these 2 accessors. 2) I don't think it is possible to have a common function instead of bunch of unique functions for each mapper declared.

lildmh marked an inline comment as done.Jun 26 2019, 9:52 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
744 ↗(On Diff #205785)

This should work on 32bit machines, since 32bit machines also use int64_t for the map type?

ABataev added inline comments.Jun 26 2019, 10:14 AM
lib/CodeGen/CGOpenMPRuntime.cpp
747 ↗(On Diff #206527)

Check the declaration of the runtime function in the runtime patch and here. size parameter here has type size_t, while in runtime part it is int64_t

8739 ↗(On Diff #203438)

Hi Lingda, something like this.

void __tgt_mapper(void *base, void *begin, size_t size, int64_t type, auto components[]) {
  // Allocate space for an array section first.
  if (size > 1 && !maptype.IsDelete)
     <push>(base, begin, size*sizeof(Ty), clearToFrom(type));
   
  // Map members.
  for (unsigned i = 0; i < size; i++) {
     // For each component specified by this mapper:
     for (auto c : components) {
       if (c.hasMapper())
         (*c.Mapper())(c.arg_base, c.arg_begin, c.arg_size, c.arg_type);
       else
         <push>(c.arg_base, c.arg_begin, c.arg_size, c.arg_type);
     }
  }
  // Delete the array section.
  if (size > 1 && maptype.IsDelete)
    <push>(base, begin, size*sizeof(Ty), clearToFrom(type));
}

void <type>.mapper(void *base, void *begin, size_t size, int64_t type) {
 auto sub_components[] = {...};
 __tgt_mapper(base, begin, size, type, sub_components);
}
lildmh marked 2 inline comments as done.Jun 26 2019, 10:50 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
747 ↗(On Diff #206527)

The runtime part uses int64_t because I see every other runtime function use int64_t instead of size_t for size, e.g., __tgt_target, __tgt_target_teams, etc., despite that they are declared to be size_t in Clang codegen. So I guess it is done on purpose? Otherwise we need to modify all these runtime function interface in the future.

8739 ↗(On Diff #203438)

Hi Alexey,

I don't think this scheme is more efficient than the current scheme. My reasons are:

  1. Most code here is essentially to generate components, i.e., we need to generate c.arg_base, c.arg_begin, c.arg_size, c.arg_type for each c in components, so there will still be a lot of code in <type>.mapper. It will not reduce the mapper function code, i.e., we will still have a bunch of unique mapper functions.
  1. This scheme will prevent a lot of compiler optimization from happening. In reality, a lot of computation should be redundant. E.g., for two components c1 and c2, c1's base may be the same as c2's begin, so the compiler will be able to eliminate these reduction computation, especially when we inline all nested mapper functions together. If we move these computation into the runtime, the compiler will not be able to do such optimization.
  1. In terms of the number of push function calls, this scheme has the exact same number of calls as the current scheme, so I don't think this scheme can bring performance benefits. The scheme should perform worse than the current scheme, because it reduces the opportunities of compiler optimization as mentioned above.
ABataev added inline comments.Jun 26 2019, 12:11 PM
lib/CodeGen/CGOpenMPRuntime.cpp
747 ↗(On Diff #206527)

I recently committed the patch that fixes this problem in clang. If you're using int64_t in the runtime, the same type must be used in clang codegen.

8739 ↗(On Diff #203438)

Hi Lingda, I'm trying to simplify the code generated by clang and avoid some unnecessary code duplications. If the complexity of this scheme is the same as proposed by you, I would prefer to use this scheme unless there are some other opinions.

  1. It is not a problem. This code is unique and is not duplicated in the different mappers.
  2. Inlining is no solution here. We still generate to much code, which is almost the same in many cases and it will lead to very ineffective codegen because we still end up with a lot of almost the same code. This also might lead to poor performance.
  3. Yes, the number of pushes is always the same, in all possible schemes. It would be good to compare somehow the performance of both schemes, at least preliminary.

Also, this solution reduces the number of required runtime functions, instead of 2 we need just 1 and, thus, we need to make fewer runtime functions calls.

I think it would better to propose this scheme as an alternate design and discuss it in the OpenMP telecon. What do you think? Or we can try to discuss it in the offline mode via the e-mail with other members.
I'm not trying to convince you to implement this scheme right now, but it would be good to discuss it. Maybe it will lead to some better ideas from others?

lildmh marked 2 inline comments as done.Jun 26 2019, 12:48 PM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
747 ↗(On Diff #206527)

That's nice to know. Then I will change the type of size to int64_t as well.

8739 ↗(On Diff #203438)

Hi Alexey,

I still prefer the current scheme, because:

  1. I don't like recursive mapper calls, which goes back to my original scheme a little bit. I really think inlining can make a big difference when we have nested mappers. These compiler optimizations are the keys to have better performance for mappers.
  2. I don't think the codegen here is inefficient. Yes there is duplicated code across different mapper functions, but why that will lead to poor performance?
  3. Although we have 2 runtime functions now, the __tgt_mapper_num_components is called only once per mapper. It should have very negligible performance impact.

But if you have a different option, we can discuss it next time in the meeting. I do have a time constraint to work on the mapper implementation. I'll no longer work in this project starting this September, and I have about 30% of my time working on it until then.

ABataev added inline comments.Jun 26 2019, 12:56 PM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Lingda,

  1. We have recursive (actually, not recursive, because you cannot use types recursively) mappers calls anyway, it is nature of struсtures/classes.
  2. We have a lot of similar code. And I'm not sure that it can be optimized out.
  3. Yes, but it means that we have n extra runtime calls, where n is the number of branches in the structure/class tree.

I see :(. I understand your concern. In this case, we could try to discuss it offline, in the mailing list, to make it a little bit faster. We just need to hear other opinions on this matter, maybe there are some other pros and cons for these schemes.

lildmh marked an inline comment as done.Jun 26 2019, 1:11 PM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Hi Alexey,

Sure, let's discuss this in the mailing list. I'll summarize it and send it to the mailing list later.

We have recursive (actually, not recursive, because you cannot use types recursively) mappers calls anyway, it is nature of struсtures/classes.

We won't have recursive calls with inlining.

We have a lot of similar code. And I'm not sure that it can be optimized out.

I think it's even harder to optimized these code out when we move them into the runtime.

Yes, but it means that we have n extra runtime calls, where n is the number of branches in the structure/class tree.

I don't quite understand. It's still equal to the number of mappers in any case.

ABataev added inline comments.Jun 26 2019, 1:20 PM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Sure, let's discuss this in the mailing list. I'll summarize it and send it to the mailing list later.

Good, thanks!

We won't have recursive calls with inlining.

We won't have recursive calls anyway (recursive types are not allowed). Plus, I'm not sure that inlining is the best option here. We have a lot of code for each mapper and I'm not sure that the optimizer will be able to squash it effectively.

I think it's even harder to optimized these code out when we move them into the runtime.

Definitely not, unless we use LTO or inlined runtime.

lildmh marked an inline comment as done.Jun 26 2019, 1:26 PM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

We won't have recursive calls anyway (recursive types are not allowed). Plus, I'm not sure that inlining is the best option here. We have a lot of code for each mapper and I'm not sure that the optimizer will be able to squash it effectively.

Sorry I should not say recursive calls. Here it needs to "recursively" call other mapper functions in case of nested mappers, but we don't need it in case of inlining.

Definitely not, unless we use LTO or inlined runtime.

But you are proposing to move many code to the runtime here, right? That doesn't make sense to me.

ABataev added inline comments.Jun 26 2019, 1:34 PM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

But you are proposing to move much code to the runtime here, right? That doesn't make sense to me.

I'm just not sure that there going be significant problems with the performance because of that. And it significantly simplifies codegen in the compiler and moves the common part into a single function.

Plus, if in future we'll need to modify this functionality for some reason, 2 different versions of the compiler will produce incompatible code. With my scheme, you still can use old runtime and have the same functionality as the old compiler and the new one.

lildmh marked an inline comment as done.Jun 27 2019, 9:48 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Hi Alexey,

I think more carefully about your scheme, and I don't think we can solve the 2 problems below with this scheme:

  1. In the example you gave before, the compiler needs to generate all map types and pass them to __tgt_mapper through sub_components. But in this case, the compiler won't be able to generate the correct MEMBER_OF field in map type. As a result, the runtime has to fix it using the mechanism we already have here: __tgt_mapper_num_components. This not only increases complexity, but also, it means the runtime needs further manipulation of the map type, which creates locality issues. While in the current scheme, the map type is generated by compiler once, so the data locality will be very good in this case.
  1. sub_components includes all components that should be mapped. If we are mapping an array, this means we need to map many components, which will need to allocate memory for sub_components in the heap. This creates further memory management burden and is not an efficient way to use memory.

Based on these reasons, I think the current scheme is still more preferable.

ABataev added inline comments.Jun 27 2019, 9:54 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Hi Lingda,

  1. Actually, I thought that the runtime function __tgt_mapper will do this, not the compiler.
  2. Why do we need to allocate it on the heap? We can allocate it on the stack.
lildmh marked an inline comment as done.Jun 27 2019, 10:04 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)
  1. In your scheme, both compiler and __tgt_mapper need to do this: the compiler will generate other parts in the type, e.g., TO FROM bits and basic MEMBER_OF bits. Then __tgt_mapper needs to modify the MEMBER_OF bits later. Since there are a lot of other memory accesses between the compiler and __tgt_mapper operations to the same map type, it's very likely the map type will not stay in the cache, which causes locality problem.
  1. Assume we are mapping an array with 1000000 elements, and each elements have 5 components. For each component, we need base, begin_ptr, size, type, mapper, which are 40 bytes. Together, we will need 1000000 * 5 * 40 = 200MB of space for this array, which stack cannnot handle.
ABataev added inline comments.Jun 27 2019, 10:09 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)
  1. I don't think it is a big problem, this part of the code is executed on the CPU and I don't think it will lead to significant overhead.
  2. When we map an array, we do not map it element-by-element, so we don't need 10000 records. Moreover, we try to merge contiguous parts into single one, reducing the total number of elements.
lildmh marked an inline comment as done.Jun 27 2019, 10:20 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)
  1. I think it is a problem. Beside, doing so is not elegant: why having a single thing (setting the map type) done in 2 places while we can do it in one place?
  1. We need to map them element by element because it is not always possible to merge contiguous parts together (there may be no contiguous parts based on the mapper). And merging parts together will be a complex procedure: I don't think it can be done in the runtime because many code is moved into the runtime now. In contrast, the compiler will have better opportunities to merge things.

Besides, I don't think there is a valid reason that the current scheme is not good. You mentioned it's complex codegen. But it only has less 200 loc here, I don't see why it is complex.

ABataev added inline comments.Jun 27 2019, 10:26 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)
  1. I rather doubt that we will need to map a record with 100000 fields element-by-element.

I think it would be better to share it with others and listen to their opinions. It is better to spend some extra time to provide good design.
You can include your doubts in the description of the new scheme, of course.

lildmh marked an inline comment as done.Jun 27 2019, 10:33 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)
  1. The implementation should work for any case anyway. Besides, I think mapping a large array should be actually a common case. The users don't want to map 1000000 elements by themselves, so they will want to use mapper to let the system do it automatically.

Sure, I can release the discussion to the mailing list. I don't see a reason to use the new scheme now.

ABataev added inline comments.Jun 27 2019, 10:58 AM
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Lingda, I meant to send the message to the OpenMP telecon list :) Could you forward the same e-mail to Ravi and others, please?

lildmh marked an inline comment as done.Jun 27 2019, 11:03 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
8739 ↗(On Diff #203438)

Sure, probably no one in the public mailing list will care about it. I'll send it to the bi-weekly meeting list.

lildmh updated this revision to Diff 206895.Jun 27 2019, 11:28 AM

Change the type of size from size_t to int64_t, and rebase

Change the type of size from size_t to int64_t, and rebase

Lingda, could you rebase it again? Thanks.

Change the type of size from size_t to int64_t, and rebase

Lingda, could you rebase it again? Thanks.

Sure, I'll do it next week, since I'm on vacation and don't have access to my desktop.

ABataev added inline comments.Jul 23 2019, 9:35 AM
lib/CodeGen/CGDecl.cpp
2533 ↗(On Diff #211278)

Why do we need to emit it for simd only mode?

lib/CodeGen/CGOpenMPRuntime.cpp
1695 ↗(On Diff #211278)

You're looking for CGF.CurFn twice here, used find member function instead and work with iterator.

7116–7124 ↗(On Diff #211278)

Maybe it is better to define a constant constexpr uint64_t OMP_MEMBER_OF_RANK = 48 and then deduce OMP_MAP_MEMBER_OF as ~((1<<OMP_MEMBER_OF_RANK) - 1)?

8116 ↗(On Diff #211278)

AFAIK, LLVM has dropped support for msvc 2013, do we still need this?

lib/CodeGen/CGOpenMPRuntime.h
352 ↗(On Diff #211278)

Use using instead of typedef.

lildmh updated this revision to Diff 211333.Jul 23 2019, 10:43 AM
lildmh marked 4 inline comments as done.
lildmh added inline comments.
lib/CodeGen/CGDecl.cpp
2533 ↗(On Diff #211278)

This code is not emitting mapper for simd only mode.

lib/CodeGen/CGOpenMPRuntime.cpp
7116–7124 ↗(On Diff #211278)

In libomptarget, the same way is used to define OMP_TGT_MAPTYPE_MEMBER_OF: OMP_TGT_MAPTYPE_MEMBER_OF = 0xffff000000000000. So I think they should stay the same. Btw, the number 48 is directly used in libomptarget now, which may need to change in the future.

In your code, it assumes bits higher than 48 are all OMP_MAP_MEMBER_OF, which may not be true in the future. My code here is more universal, although it does not look great. What do you think?

ABataev added inline comments.Jul 23 2019, 11:11 AM
lib/CodeGen/CGDecl.cpp
2533 ↗(On Diff #211278)

Ah, yes, it is the condition for the early exit.

lib/CodeGen/CGOpenMPRuntime.cpp
7116–7124 ↗(On Diff #211278)

You can apply a mask to drop some of the most significant bits if required. My code looks much cleaner it would be good to have the same code in libomptarget too.
But it is up to you what to do here.

8116 ↗(On Diff #211278)

Ping.

lib/CodeGen/CGOpenMPRuntime.h
810–815 ↗(On Diff #211333)

I don't think we need virtual functions here, non-virtual are good enough.

2110 ↗(On Diff #211333)

I think you can drop this function here if the original function is not virtual

lildmh marked 3 inline comments as done.Jul 23 2019, 11:37 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.cpp
7116–7124 ↗(On Diff #211278)

Maybe let's keep it this way in this patch, then we modify both places in a further patch?

8116 ↗(On Diff #211278)

I'm okay either way. I guess it doesn't hurt to keep it?

lib/CodeGen/CGOpenMPRuntime.h
2110 ↗(On Diff #211333)

The function for simd only mode includes a llvm_unreachable, so I think it's still needed as a virtual function above

ABataev added inline comments.Jul 23 2019, 11:42 AM
lib/CodeGen/CGOpenMPRuntime.h
2110 ↗(On Diff #211333)

It is better to reduce number of virtual functions, if possible.

lildmh updated this revision to Diff 211589.Jul 24 2019, 12:50 PM

Get rid of MSVC requirement of this, and a virtual function

ABataev added inline comments.Jul 24 2019, 12:57 PM
lib/CodeGen/CGOpenMPRuntime.h
2110 ↗(On Diff #211333)

What about virtual function?

lildmh marked an inline comment as done.Jul 25 2019, 3:45 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.h
2110 ↗(On Diff #211333)

Since emitUserDefinedMapper here overrides the same function in CGOpenMPRuntime, I think emitUserDefinedMapper of CGOpenMPRuntime needs to be defined as virtual?

lildmh marked an inline comment as done.Jul 25 2019, 3:47 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.h
2110 ↗(On Diff #211333)

If you are asking about what virtual function I removed, it is emitUDMapperArrayInitOrDel of CGOpenMPRuntime which is never overrided.

ABataev added inline comments.Jul 25 2019, 6:59 AM
lib/CodeGen/CGOpenMPRuntime.h
2110 ↗(On Diff #211333)

I would suggest to not make this virtual too and remove overriden version. It does not help.

lildmh marked an inline comment as done.Jul 25 2019, 8:48 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.h
2110 ↗(On Diff #211333)

If we remove virtual from emitUserDefinedMapper, we will have to define it in both CGOpenMPRuntime and CGOpenMPSIMDRuntime, and its definition is identical in both places. I don't think that's good software engineering practice?

ABataev added inline comments.Jul 25 2019, 8:52 AM
lib/CodeGen/CGOpenMPRuntime.h
2110 ↗(On Diff #211333)

WE just don't need an overridden version in CGOpenMPSIMDRuntime. Just remove virtual and remove the overridden function from CGOpenMPSIMDRuntime.
You have the check for OpenMPSimd mode that prevents the emission of mappers in simd-only mode.

lildmh updated this revision to Diff 211794.Jul 25 2019, 11:14 AM

Remove virtual from function declaration

ABataev added inline comments.Jul 26 2019, 10:33 AM
lib/CodeGen/CGOpenMPRuntime.h
815 ↗(On Diff #211794)

Seems to me, this function is used only in emitUserDefinedMapper. I think you can make it static local in the CGOpenMPRuntime.cpp and do not expose it in the interface.

lildmh marked an inline comment as done.Jul 26 2019, 11:01 AM
lildmh added inline comments.
lib/CodeGen/CGOpenMPRuntime.h
815 ↗(On Diff #211794)

emitUserDefinedMapper needs to call createRuntimeFunction of CGOpenMPRuntime, which is private.

Which one do you think is better, make createRuntimeFunction public, or have emitUserDefinedMapper not defined in CGOpenMPRuntime? It seems to me that they are similar

ABataev added inline comments.Jul 26 2019, 11:37 AM
lib/CodeGen/CGOpenMPRuntime.h
815 ↗(On Diff #211794)

Then make emitUDMapperArrayInitOrDel private instead.

lildmh updated this revision to Diff 211991.Jul 26 2019, 12:52 PM

Make emitUDMapperArrayInitOrDel private

ABataev accepted this revision.Jul 26 2019, 1:45 PM

Looks good in general, but commit the runtime part at first.

test/OpenMP/declare_mapper_codegen.cpp
44–48 ↗(On Diff #211991)

I would not rely on the predetermined indices here, better to use some kind of patterns here just like in other places.

289–293 ↗(On Diff #211991)

Same here

This revision is now accepted and ready to land.Jul 26 2019, 1:45 PM
lildmh marked an inline comment as done.Jul 29 2019, 12:09 PM

Thanks Alexey! Could you look into the runtime patch D60972 then?

test/OpenMP/declare_mapper_codegen.cpp
44–48 ↗(On Diff #211991)

Could you give an example about what you suggest? For instance, some other tests I should look into.

ABataev added inline comments.Jul 29 2019, 12:57 PM
test/OpenMP/declare_mapper_codegen.cpp
44–48 ↗(On Diff #211991)

Just like in this test when you're using vars.

lildmh marked an inline comment as done.Jul 29 2019, 1:19 PM
lildmh added inline comments.
test/OpenMP/declare_mapper_codegen.cpp
44–48 ↗(On Diff #211991)

Sorry I was not clear before. What do you mean by "predetermined indices" here? If you are referring to, for example, %0 in store i8* %0, i8** [[HANDLEADDR:%[^,]+]], I guess there is no way to get rid of %0 because it means the first argument of the function?

ABataev added inline comments.Jul 29 2019, 1:21 PM
test/OpenMP/declare_mapper_codegen.cpp
44–48 ↗(On Diff #211991)

Yes, I meant those %0 like registers. Better to mark them as variables in function declaration and use those names in the checks.

lildmh marked an inline comment as done.Jul 29 2019, 1:44 PM
lildmh added inline comments.
test/OpenMP/declare_mapper_codegen.cpp
44–48 ↗(On Diff #211991)

Now it's like define {{.*}}void @.omp_mapper.{{.*}}C.id{{.*}}(i8*, i8*, i8*, i64, i64), I think you are suggesting something like define {{.*}}void @.omp_mapper.{{.*}}C.id{{.*}}(i8* [[HANDLE:%[^,]+]], i8* [[BPTR:%[^,]+]], ...), and later I can use store i8* [[HANDLE]], i8** [[HANDLEADDR:%[^,]+]]

I'm not sure how to add names for function arguments. They seems to be always nameless like (i8*, i8*, i8*, i64, i64). Is there a way to do that?

ABataev added inline comments.Jul 29 2019, 2:00 PM
test/OpenMP/declare_mapper_codegen.cpp
44–48 ↗(On Diff #211991)

If the clang parameters have names, the llvm params also will get the names. But it is not worth it to add the names to the function. Could just use regexp here to avoid using LLVM register names? Just %{{·+}}. And rely on the order, i.e. remove -DAG checks?

lildmh updated this revision to Diff 212399.Jul 30 2019, 11:44 AM
lildmh marked an inline comment as done.

Change mapper function argument checking

Thanks, looks good.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2019, 9:18 PM
lildmh updated this revision to Diff 213339.Aug 5 2019, 5:57 AM

Fix declare mapper codegen test when the function argument has name attached.