Hi,

Currently, the only pragma directives that can be added by a backend, only have
access to the information on the same line as the pragma, which is enough for
modifying a global state.

This means that a loop target pragma could look like this:
#pragma target begin keyword [options]
<The loop>
#pragma target end keyword

However, the coupling between the code in-between the two pragmas and its
semantic is not preserved; moreover it's not possible to know if a loop is
included within the region at parse time.  The second point, is that it does not
work because all the pragmas are resolved at parse time, hence it is not
possible to observe the state of the region when performing optimizations.

It would be nice to have something similar to what clang offers (Language
Extensions: Extensions for loop hint optimizations [1]). So that it's clear that
the pragma is tied to a loop and there is no need for "begin" and "end"
region-delimiters.

Leaving aside OpenMP's pragma directives, the only loop-specific pragmas
provided by GCC are "unroll" and "ivdep".  The parsing of those are very much
hard-wired into the front-ends.  The function dealing with the parsing of loops
in the C and C++ front-end all take "ivdep" and "unroll" as an explicit
argument.  The Fortran front-end deals with them a bit differently but they are
very much hardwired as well there.

This means that for each new loop-specific pragma all those functions should be
augmented with a new parameter, and the loop structure be updated with a new
field.

My current idea to implement this is:
  (1) Add a field "struct loop_info tinfo" to the loop class in cfgloop.h
  (2) The tinfo structure would contain the fields for the target independent
  loop information (that is unroll, and ivdep).
  (3) More fields could be added to this structure through a TARGET macro, it
  would looks like:

    struct loop_info tinfo {
      bool ivdep;
      unsigned short unroll;
      #ifdef TARGET_LOOP_INFO_FIELDS
        TARGET_LOOP_INFO_FIELDS
      #endif
    };

  (4) The annot_expr_kind enum should be extendable in the same way through a
  TARGET macro (TARGET_ANNOTATE_EXPR).
  (5) The callback hook processing the pragma should receive a pointer to the
  TINFO structure.
  (6) A new hook should be introduced for creating the ANNOTATE_EXPR on the loop
  condition.  This hook will be called by the loop parsing function.
  (7) The function replace_loop_annotate_in_block would iterate over the kinds
  described by the enum annot_expr_kind, and call a new hook to process the
  annotate expr.

In summary, in would require a new structure, the modification of the
prototypes of the loop parsing functions, two new TARGET macros, a new kind of
pragma hook for loop-specific pragma, and two new TARGET hooks.

I don't really like the fact that TARGET_LOOP_INFO_FIELDS and
TARGET_ANNOTATE_EXPR contains enum and struct fragments, another approach could
be to use a hash-table.

Thanks,
Paul

[1]: https://clang.llvm.org/docs/LanguageExtensions.html#id39




Reply via email to