From: Iain Sandoe <idsandoe@googlemail.com>
To: Martin Liska <mliska@suse.cz>
Cc: Richard Biener <richard.guenther@gmail.com>,
Jan Hubicka <hubicka@kam.mff.cuni.cz>,
GCC Development <gcc@gcc.gnu.org>
Subject: Re: [GSoC]Bypass assembler when generating LTO object files
Date: Tue, 12 Apr 2022 13:52:59 +0100 [thread overview]
Message-ID: <858304E4-5B02-4164-8E5B-16C2385A30E7@googlemail.com> (raw)
In-Reply-To: <57c21fe6-4992-f54d-3f90-b1c4c9fa7b98@suse.cz>
> On 12 Apr 2022, at 13:31, Martin Liška <mliska@suse.cz> wrote:
>
> On 4/12/22 11:58, Richard Biener wrote:
>> On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc <gcc@gcc.gnu.org> wrote:
>>>
>>> Hi,
>>>>
>>>>
>>>>> On 08-Apr-2022, at 6:32 PM, Jan Hubicka <hubicka@kam.mff.cuni.cz> wrote:
>>>>>
>>>>> Ankur,
>>>>>> I was browsing the list of submitted GSoC projects this year and the
>>>>>> project regarding bypassing assembler when generating LTO object files
>>>>>> caught my eye.
>>>>> I apologize for late reply. I would be very happy to mentor this
>>>>> project.
>>>>
>>>> Thanks for the reply, but unfortunately, due to some reasons, I would not
>>>> be able to take part in GSoC this year.
>>>> But the project seems interesting and would be amazing opportunity to
>>>> learn a lot more things for me, so would it be okay if I try to give it a
>>>> go outside GSoC if no-one else picks it as their GSoC project this year ?
>>>
>>> I would be still very happy to help with that! However it would be also
>>> pity to not take part of GSoC, so if there is something I can help with
>>> on that let me know.
>>>>
>>>>>>
>>>>>> I already have a gcc built from source (sync-ed with trunk/master) and
>>>>>> launched the test-suite on it.
>>>>>>
>>>>>> I am currently in process of understanding the primilary patch
>>>>>> (https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and
>>>>>> experimenting with it.
>>>>>>
>>>>>> are there any other things I should be aware of (useful Doc/blog or a
>>>>>> bug tracking the project) before proceeding further ?
>>>>>
>>>>> I think it is pretty much all that exists. Basically we will need to
>>>>> implement everything that is necessary to stream out valid object file
>>>>> directly from GCC rather than going through gas. The experimental
>>>>> prototype sort of worked but it was lacking few things.
>>>>
>>>> When I try to apply that patch on my local branch ( branched from trunk ),
>>>> it seem to be incompatible with the current working tree. Is there a
>>>> specific branch that I have to apply it to ? or is it due to the recent
>>>> file rename patch ( changing extensions from .c to .cc ) ?
>>>>
>>>> ```
>>>> $ git apply --check bypass_asm_patch
>>>>
>>>> error: patch failed: Makefile.in:1300
>>>> error: Makefile.in: patch does not apply
>>>> error: common.opt: No such file or directory
>>>> error: langhooks.c: No such file or directory
>>>> error: lto/Make-lang.in: No such file or directory
>>>> error: lto/lto-object.c: No such file or directory
>>>> error: lto/lto.c: No such file or directory
>>>> error: lto/lto.h: No such file or directory
>>>> error: lto-streamer.h: No such file or directory
>>>> error: toplev.c: No such file or directory
>>>> ```
>>>
>>> I can try to update the patch, or it probably should apply to trunk
>>> checked out around the date I sent the patch. Indeed we need to change
>>> c to cc but there are likely more changes since then - most importnatly
>>> the early debug info.
>>> At I will see how easy/hard is to make the patch build with current
>>> trunk.
>> We do have ideas for the early debug with the asm-out abstraction to
>> also solve a different issue (missing simple-object support for mingw/darwin).
>
> Note the debug info will be stored to a different .s file, then the file
> will be converted .o by GAS and then the bytecode will be stored to an ELF
> section of a compiled object. I've got also binutils patch when we'll
> be able to directly use the embedded section with compile.o@offset.
Which will not work, as written, for Darwin since that is neither ELF nor does it
use GAS - but hopefully, we can find some equivalent mechanism (there is already
some support in the Darwin backend for switching asm context for LTO output).
>> Namely assemble the early debug in a different file and include the resulting
>> native object in binary form in the compile output - not needing to write
>> assembly .data for that would be a good way to make this more viable.
>
> Btw. do you have any estimation how slow is GAS when we speak about debug info?
> How much time can we save since the latest speed-up achieved by GAS?
>
>> You might want to talk to Martin Liska for this who I think had some
>> prototype on this?
>
> I can provide a prototype if needed.
I’d like to be in to loop from the Darwin PoV..
thanks
Iain
>
> Cheers,
> Martin
>
>> Richard.
>>> Honza
>>>>
>>>> Thanks
>>>> - Ankur
next prev parent reply other threads:[~2022-04-12 12:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-06 13:30 Ankur Saini
2022-04-08 13:02 ` Jan Hubicka
2022-04-12 4:13 ` Ankur Saini
2022-04-12 9:18 ` Jan Hubicka
2022-04-12 9:58 ` Richard Biener
2022-04-12 12:31 ` Martin Liška
2022-04-12 12:52 ` Iain Sandoe [this message]
2022-04-12 13:41 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=858304E4-5B02-4164-8E5B-16C2385A30E7@googlemail.com \
--to=idsandoe@googlemail.com \
--cc=gcc@gcc.gnu.org \
--cc=hubicka@kam.mff.cuni.cz \
--cc=mliska@suse.cz \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).