[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