Ping (https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662211.html)
On Wed, Sep 04, 2024 at 01:56:59PM +0200, Paul Iannetta wrote:
> 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
