Re: Q: What is default architecture for code produced by native compiler?

[Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> Date: Wed, 25 Aug 2021 07:36:59 +0000
>> From:  Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
>> 
>> > (setq native-comp-driver-options '("-march=native" "-mcpu=native"))
>> >
>> > but I see no difference in emitted code when I dissaemble produced binaries.
>> 
>> Driver options are not for the compiler but rather linker and assembler,
>> infact `native-comp-driver-options' relies on
>> 'gcc_jit_context_add_driver_option' [1].
>
> Then the name of the defcustom is misleading, IMO.

You are probably right, the defcustom name is inherited from the
libgccjit entry point name but it is probably not optimal.  Any
suggestion for a better one?

> These can only be
> the options that cc1 (or assembler/linker) understands, is that right?
>
> And I guess this means we cannot support GCC options, because there's
> no front-end driver like GCC in libgccjit?

To make it more clear I think we can summarize the situation as:

| libgccjit entry-point                   | affects what | emacs customize            |
|-----------------------------------------+--------------+----------------------------|
| gcc_jit_context_add_driver_option       | gas + ld     | native-comp-driver-options |
| gcc_jit_context_add_command_line_option | cc1          | ??                         |

So yes, exposing 'gcc_jit_context_add_command_line_option' we could.

Regards

  Andrea