I believe some of these points are being addressed by #7204 - but this is not live yet.

That should resolve -debug and some form of LLVM IR by using --keep-temp-files instead of using -build-mode:llvm-ir? - though maybe it's still needed, we'll have to test.

The initial PR that added Odin attempted to filter out non-user code by our regex filter, but this is indeed missing the register/deregister and framedummy https://github.com/compiler-explorer/compiler-explorer/pull/7186/files#diff-63ec575c9a5348bc50d6c6570e5a5b457d07ac1e2aa22320c8cbe9e9f1f20516R14 - that would need to be added like we also do with c++ for example https://github.com/compiler-explorer/compiler-explorer/blob/main/etc/config/c%2B%2B.defaults.properties#L147

What does -no-entry-point do and can it be undone by additional user arguments?

Regarding [1] Does this require extra metadata to be produced alongside the compilation? - maybe, we have ways to deal with it, but it depends on how much effort it would cost to write a custom parser / if our current parsers can support it out of the box. The original PR mentioned this in the comments https://github.com/compiler-explorer/compiler-explorer/pull/7186/files#diff-63ec575c9a5348bc50d6c6570e5a5b457d07ac1e2aa22320c8cbe9e9f1f20516R8 about our library filter and so it might require extra testing and maybe extra parsing.

Good to know that #7204 might address some of my points.

-no-entry-point just removes the requirement for the main procedure to be defined within the entry package. It cannot be "undone" with any flags because it an opt-in thing. Maybe I am wrong, but wouldn't adding this flag make it more comparable to other languages like C/C++ so you can write Odin code without the entry-point procedure main?

As for the [1] point. I could easily add a feature to compiler that just returns a JSON file that shows only the procedures that are declared in that file, allowing the user to inspect what the generated assembly is.

-no-entry-point just removes the requirement for the main procedure to be defined within the entry package. It cannot be "undone" with any flags because it an opt-in thing. Maybe I am wrong, but wouldn't adding this flag make it more comparable to other languages like C/C++ so you can write Odin code without the entry-point procedure main?

That would then be a bad idea to do. We sometimes automatically generate a main() when it's missing, but I would say it's generally a bad practice.

Some notes about the current status/issues:

• The "Library Filter" is now enabled, and for the default hello world sample it produces ~8000 lines of asm compared to previous ~45K. Which is an improvement. Be sure to enable the library filter, its a checkbox inside the "Filter..." button.
• But why do we have ~8k lines, why don't they get filtered out? I debugged this a little bit and so far I discovered that
  • odin has a special kind of label which isn't covered by the current label matching regex. For e.g., "runtime._stderr_write-993":. Notice the quotes and -. The default label matching regex is here:

    compiler-explorer/lib/parsers/asmregex.ts

    Line 34 in 0a2f5f2

    this.labelDef = /^(?:.proc\s+)?([\w$.@]+):/i;

  • I tried adding adding a subclass of AsmParser and overriding the regex to match correctly but it didn't have the intended effect of removing unused functions. Instead it just removed all the labels from the asm for some reason. So this needs to be debugged a bit more to find out why compiler explorer is struggling with removing rest of the functions
  • The runtime functions such as __$startup_runtime: and other __$* functions and should perhaps be removed during a preprocessAsm
• The reason for using -keep-temp-files is because we can only have 1 -build-mode:* option. We need both asm and llvm-ir output at the same time, from a single command.
• -debug is enabled by default
• register_tm_clones and any other such function from the "objdump" output can be removed by extending the binaryHideFuncRe.

As for the [1] point. I could easily add a feature to compiler that just returns a JSON file that shows only the procedures that are declared in that file, allowing the user to inspect what the generated assembly is.

This can work but we'll need a custom IAsmParser class to handle this. But I feel this is unnecessary, its normal gnu asm. With some effort we can probably get what we want.

Besides all this, I think it would be good if Odin compiler provided an option to emit intel style asm. Most people I know prefer intel style asm over gnu.