Refactor/dirs

[leissa]

• split sources into include/ and src/
• also plugins have their own include/ + src dir structure like this:

  
  thorin/
      plugins/
          autodiff/
              autodiff.thorin
              CMakeLists.txt
              include/
              src/
          core/
              core.thorin
              CMakeLists.txt
              include/
              src/
      ...

• plugins also live in thorin::plug such as thorin::plug::mem::SSAConstr.
• removed all traces of "dialect"
• plugin/fp and plugin/rw -> plugin I sometimes find myself moving passes between these two subdirs as they change from FPPass and RWPass or vice versa and some plugins weren't using these subdirs anyway.
• Thorin's CLI got a new option --output-d and spits out a dependency file similar to -M in gcc
• add_thorin_plugin got an overhaul and uses the new flag to automatically track dependencies of *.thorin files

add_thorin_plugin(<plugin_name>
    [SOURCES <source>...]
    [HEADERS <header>...]
    [PRIVATE <private_item>...]
    [INTERFACE <interface_item>...]
    [PUBLIC <public_item>...]
    [INSTALL])

The <plugin_name> is expected to be the name of the plugin. This means, there should be (relative to your CMakeLists.txt) a file <plugin_name>.thorin containing the axiom declarations. This will generate a header plug/<plugin_name>/autogen.h that can be used in normalizers and passes to identify the axioms. The command will create three targets:

1. thorin_internal_<plugin_name>: This is an internal target to bootstrap the plugin, i.e. generate the header etc.
2. thorin_interface_<plugin_name>: This is a header-only INTERFACE library that consists of all <header> files. It "links" via INTERFACE with all <interface_item> targets. This means everybody who links to thorin_interface_<plugin_name> will also have access to the include directories of these targets. In addition, thorin_interface_<plugin_name> depends on thorin_internal_<plugin_name>.
3. thorin_<plugin_name>: This is the actual MODULE library and conists of all <source> files and links PUBLIC to thorin_interface_<plugin_name>. Thus, all sources will have access to the headers of thorin_interface_<plugin_name> and to all other targets specified via INTERFACE. Furthermore, you can specify additional public_item targets that the module should link against as PUBLIC. Finally, you can specify additional <private_item> build dependencies.

The <source> files are used to build the loadable plugin containing normalizers, passes and backends. One of the source files must export the thorin_get_plugin function. Custom properties can be specified in the CMakeLists.txt file, e.g. adding include paths is done with target_include_directories(thorin_<plugin_name> <path>...).

[leissa]

@NeuralCoder3, @fodinabor: bump

[NeuralCoder3]

Currently, the path of a file pass.cpp in a plugin is plugins/[name]/src/thorin/plug/[name]/pass/pass.cpp. Which seems extensively long (nearly java level). An advantage is that the local path corresponds directly to the build path of the files. However, conceptually, all files you want to create in the source of your plugin are usually in the thorin/plug/[name] scope. Hence, we could maybe shorten this and just have plugins/[name]/src/pass/pass.cpp.

[leissa]

Currently, the path of a file pass.cpp in a plugin is plugins/[name]/src/thorin/plug/[name]/pass/pass.cpp. Which seems extensively long (nearly java level). An advantage is that the local path corresponds directly to the build path of the files. However, conceptually, all files you want to create in the source of your plugin are usually in the thorin/plug/[name] scope. Hence, we could maybe shorten this and just have plugins/[name]/src/pass/pass.cpp.

yeah, paths are getting quite long. I do like that the src path mirrors the include path and your suggestion would only fix the src files anyway. I already removed the rw/fp subdirs from pass to mitigate some of the pain. Other options may include:

• merge thorin/plug/ to thorplug or sth like this (which I find quite weird)
• I thought about removing the pass part as this thing does not mirror a sub namespace but on the other hand, it's quite useful to have to navigate

In the end of the day, if you use a vim-plugin such as ctrlp or sth similar, the dir structure doesn't matter that much.