emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrea Corallo
Subject: Re: Q: What is default architecture for code produced by native compiler?
Date: Wed, 25 Aug 2021 13:04:25 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]