Update the way reduction operator are defined for the OpenACC parser.
Sorry, I have not gone into detail here. But could you provide some motivation/explanation for this change? Is this because OpenACC accepts fewer or different reduction operators. Or is a similar change required in OpenMP too.
In the current state, only reduction with + and * would be parsed and resolved correctly. We would need an intrinsic function name resolution in place to accept the others operators and also a semantic check to discard all intrinsic that are not accepted as reduction operators. So in order to simply thing, a simple enumeration seemed a better replacement. OpenACC doesn't accept user-defined reduction operator (as of 3.0) so we can make this simplification. For OpenMP, as you can use user-defined operator I guess you will have to put in place a function name resolution for those reduction operators. But in the current state the openmp reduction operator such as max or min are likely to fail at name resolution.
For my information: Why is source needed here?
What I meant to say here is that previously the OpenACCReductionOperator was defined in terms of struct DefinedOperator which in turn is defined in terms of DefinedOpName or IntrinsicOperator. If these are also used for the Fortran expressions in the parse tree then it is easy to match the OpenACC Reduction Operation and the operation in Fortran source where reduction is implied. If you use your own custom definitions for operations then there is some code that you have to write to do the matching.
Ok I see now. Yeah you are right in case I need to do a matching (which is still unclear at this stage) there would be some code to be written to do that. But my guess right now is that we can lower this directly to the dialect without the need to match an operation since what we need are the values taking part in the reduction to issue the correct operation.