From: "H.J. Lu" <hjl.tools@gmail.com>
To: Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>
Cc: Richard Biener <richard.guenther@gmail.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PR47785] COLLECT_AS_OPTIONS
Date: Tue, 29 Oct 2019 16:26:00 -0000 [thread overview]
Message-ID: <CAMe9rOqcw_n2koqMH_4V28K15mpFXAyyCLzux+8aLxzJ1a-x2A@mail.gmail.com> (raw)
In-Reply-To: <CAELXzTPNeXjRUYGmExzobs6+WiEpNx_5SBuDyz7D7t-xhSBMvw@mail.gmail.com>
On Sun, Oct 27, 2019 at 6:33 PM Kugan Vivekanandarajah
<kugan.vivekanandarajah@linaro.org> wrote:
>
> Hi Richard,
>
> Thanks for the review.
>
> On Wed, 23 Oct 2019 at 23:07, Richard Biener <richard.guenther@gmail.com> wrote:
> >
> > On Mon, Oct 21, 2019 at 10:04 AM Kugan Vivekanandarajah
> > <kugan.vivekanandarajah@linaro.org> wrote:
> > >
> > > Hi Richard,
> > >
> > > Thanks for the pointers.
> > >
> > >
> > >
> > > On Fri, 11 Oct 2019 at 22:33, Richard Biener <richard.guenther@gmail.com> wrote:
> > > >
> > > > On Fri, Oct 11, 2019 at 6:15 AM Kugan Vivekanandarajah
> > > > <kugan.vivekanandarajah@linaro.org> wrote:
> > > > >
> > > > > Hi Richard,
> > > > > Thanks for the review.
> > > > >
> > > > > On Wed, 2 Oct 2019 at 20:41, Richard Biener <richard.guenther@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Oct 2, 2019 at 10:39 AM Kugan Vivekanandarajah
> > > > > > <kugan.vivekanandarajah@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > As mentioned in the PR, attached patch adds COLLECT_AS_OPTIONS for
> > > > > > > passing assembler options specified with -Wa, to the link-time driver.
> > > > > > >
> > > > > > > The proposed solution only works for uniform -Wa options across all
> > > > > > > TUs. As mentioned by Richard Biener, supporting non-uniform -Wa flags
> > > > > > > would require either adjusting partitioning according to flags or
> > > > > > > emitting multiple object files from a single LTRANS CU. We could
> > > > > > > consider this as a follow up.
> > > > > > >
> > > > > > > Bootstrapped and regression tests on arm-linux-gcc. Is this OK for trunk?
> > > > > >
> > > > > > While it works for your simple cases it is unlikely to work in practice since
> > > > > > your implementation needs the assembler options be present at the link
> > > > > > command line. I agree that this might be the way for people to go when
> > > > > > they face the issue but then it needs to be documented somewhere
> > > > > > in the manual.
> > > > > >
> > > > > > That is, with COLLECT_AS_OPTION (why singular? I'd expected
> > > > > > COLLECT_AS_OPTIONS) available to cc1 we could stream this string
> > > > > > to lto_options and re-materialize it at link time (and diagnose mismatches
> > > > > > even if we like).
> > > > > OK. I will try to implement this. So the idea is if we provide
> > > > > -Wa,options as part of the lto compile, this should be available
> > > > > during link time. Like in:
> > > > >
> > > > > arm-linux-gnueabihf-gcc -march=armv7-a -mthumb -O2 -flto
> > > > > -Wa,-mimplicit-it=always,-mthumb -c test.c
> > > > > arm-linux-gnueabihf-gcc -flto test.o
> > > > >
> > > > > I am not sure where should we stream this. Currently, cl_optimization
> > > > > has all the optimization flag provided for compiler and it is
> > > > > autogenerated and all the flags are integer values. Do you have any
> > > > > preference or example where this should be done.
> > > >
> > > > In lto_write_options, I'd simply append the contents of COLLECT_AS_OPTIONS
> > > > (with -Wa, prepended to each of them), then recover them in lto-wrapper
> > > > for each TU and pass them down to the LTRANS compiles (if they agree
> > > > for all TUs, otherwise I'd warn and drop them).
> > >
> > > Attached patch streams it and also make sure that the options are the
> > > same for all the TUs. Maybe it is a bit restrictive.
> > >
> > > What is the best place to document COLLECT_AS_OPTIONS. We don't seem
> > > to document COLLECT_GCC_OPTIONS anywhere ?
> >
> > Nowhere, it's an implementation detail then.
> >
> > > Attached patch passes regression and also fixes the original ARM
> > > kernel build issue with tumb2.
> >
> > Did you try this with multiple assembler options? I see you stream
> > them as -Wa,-mfpu=xyz,-mthumb but then compare the whole
> > option strings so a mismatch with -Wa,-mthumb,-mfpu=xyz would be
> > diagnosed. If there's a spec induced -Wa option do we get to see
> > that as well? I can imagine -march=xyz enabling a -Wa option
> > for example.
> >
> > + *collect_as = XNEWVEC (char, strlen (args_text) + 1);
> > + strcpy (*collect_as, args_text);
> >
> > there's strdup. Btw, I'm not sure why you don't simply leave
> > the -Wa option in the merged options [individually] and match
> > them up but go the route of comparing strings and carrying that
> > along separately. I think that would be much better.
>
> Is attached patch which does this is OK?
>
Don't you need to also handle -Xassembler? Since -Wa, doesn't work with comma in
assembler options, like -mfoo=foo1,foo2, one needs to use
-Xassembler -mfoo=foo1,foo2
to pass -mfoo=foo1,foo2 to assembler.
--
H.J.
next prev parent reply other threads:[~2019-10-29 16:11 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-02 8:39 Kugan Vivekanandarajah
2019-10-02 10:41 ` Richard Biener
2019-10-11 5:42 ` Kugan Vivekanandarajah
2019-10-11 11:37 ` Richard Biener
2019-10-21 9:22 ` Kugan Vivekanandarajah
2019-10-23 12:12 ` Richard Biener
2019-10-28 3:32 ` Kugan Vivekanandarajah
2019-10-28 22:02 ` Bernhard Reutner-Fischer
2019-10-28 22:11 ` Richard Earnshaw
2019-10-29 7:53 ` Bernhard Reutner-Fischer
2019-10-29 9:02 ` Richard Biener
2019-10-28 22:36 ` Kugan Vivekanandarajah
2019-10-29 16:26 ` H.J. Lu [this message]
2019-11-01 1:33 ` Kugan Vivekanandarajah
2019-11-01 15:49 ` H.J. Lu
2019-11-04 2:46 ` Kugan Vivekanandarajah
2019-11-04 16:57 ` H.J. Lu
2019-11-04 23:17 ` Kugan Vivekanandarajah
2019-11-05 12:08 ` Richard Biener
2019-11-08 2:36 ` Kugan Vivekanandarajah
2019-11-14 12:30 ` Richard Biener
2020-01-08 10:20 ` Prathamesh Kulkarni
2020-01-15 9:47 ` Prathamesh Kulkarni
2020-01-17 17:04 ` H.J. Lu
2020-01-20 10:32 ` Richard Biener
2020-01-24 8:29 ` Prathamesh Kulkarni
2020-01-28 12:06 ` Richard Biener
2020-01-30 7:10 ` Prathamesh Kulkarni
2020-01-30 13:49 ` Richard Biener
2020-02-03 11:37 ` Prathamesh Kulkarni
2020-02-04 14:14 ` Richard Biener
2020-02-06 12:49 ` Prathamesh Kulkarni
2020-02-06 13:12 ` Richard Biener
2020-02-06 14:34 ` Prathamesh Kulkarni
2020-02-17 9:28 ` Prathamesh Kulkarni
2020-02-17 14:22 ` Richard Biener
2020-02-18 12:52 ` Prathamesh Kulkarni
2020-02-18 14:10 ` Richard Biener
2020-02-18 23:19 ` Prathamesh Kulkarni
2020-02-19 14:24 ` Richard Biener
2020-02-24 6:32 ` Prathamesh Kulkarni
2020-02-24 13:10 ` Christophe Lyon
2020-02-25 6:18 ` Prathamesh Kulkarni
2021-04-09 20:16 ` [GCC 9] " H.J. Lu
2021-04-12 9:40 ` 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=CAMe9rOqcw_n2koqMH_4V28K15mpFXAyyCLzux+8aLxzJ1a-x2A@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kugan.vivekanandarajah@linaro.org \
--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).