Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181114204309.18645-1-namit@vmware.com> <20181114204309.18645-2-namit@vmware.com>
 <CAK7LNAREF_Pcejq1LJ=3K7h0M4o4oSRLfbeJc73O+8HV420Ziw@mail.gmail.com> <1C316B94-8F27-439C-B049-9947DC329780@vmware.com>
In-Reply-To: <1C316B94-8F27-439C-B049-9947DC329780@vmware.com>
From:   Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Sun, 18 Nov 2018 13:20:39 +0900
Message-ID: <CAK7LNATFVHnPXh-uEA+T9QNw3OnSvkLLKMuJ_tF1v8bEveStSg@mail.gmail.com>
Subject: Re: [PATCH v2 1/2] Makefile: Fix distcc compilation with x86 macros
To:     Nadav Amit <namit@vmware.com>
Cc:     Ingo Molnar <mingo@redhat.com>,
        Michal Marek <michal.lkml@markovi.net>,
        Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Nov 17, 2018 at 6:02 AM Nadav Amit <namit@vmware.com> wrote:
>
> From: Masahiro Yamada
> Sent: November 16, 2018 at 7:45:45 AM GMT
> > To: Nadav Amit <namit@vmware.com>
> > Cc: Ingo Molnar <mingo@redhat.com>, Michal Marek <michal.lkml@markovi.n=
et>, Thomas Gleixner <tglx@linutronix.de>, Borislav Petkov <bp@alien8.de>, =
H. Peter Anvin <hpa@zytor.com>, X86 ML <x86@kernel.org>, Linux Kbuild maili=
ng list <linux-kbuild@vger.kernel.org>, Linux Kernel Mailing List <linux-ke=
rnel@vger.kernel.org>
> > Subject: Re: [PATCH v2 1/2] Makefile: Fix distcc compilation with x86 m=
acros
> >
> >
> > On Thu, Nov 15, 2018 at 1:01 PM Nadav Amit <namit@vmware.com> wrote:
> >> Introducing the use of asm macros in c-code broke distcc, since it onl=
y
> >> sends the preprocessed source file. The solution is to break the
> >> compilation into two separate phases of compilation and assembly, and
> >> between the two concatenate the assembly macros and the compiled (yet
> >> not assembled) source file. Since this is less efficient, this
> >> compilation mode is only used when distcc or icecc are used.
> >>
> >> Note that the assembly stage should also be distributed, if distcc is
> >> configured using "CFLAGS=3D-DENABLE_REMOTE_ASSEMBLE".
> >>
> >> Reported-by: Logan Gunthorpe <logang@deltatee.com>
> >> Signed-off-by: Nadav Amit <namit@vmware.com>
> >
> >
> > Wow, this is so ugly.
>
> Indeed, it is not pretty from the Makefile system point of view.
>
> But it does have merits when it comes to the actual use (by developers). =
If
> you look on x86, there are a lot of duplicated implementation for C and A=
sm
> and crazy C macros, for example for PV function call or the alternative
> mechanism. The code is also less readable in its current form.
>
> > I realized how much I hated this by now.
> >
> > My question is, how long do we need to carry this?
>
> If it is purely about performance, I am not sure it would make sense to
> put it in, as it will indeed be (eventually) solved by the compiler, and
> the penalty is not too great.


It is unfortunate to mess up the code
by having two different ways to achieve the same goal.

When GCC with asm inline support is shipped,
would you revert 77b0bf55 ?


> There is also an advantage for having assembly macros that can override t=
he
> generated assembly that was generated by the compiler. I think HPA (cc=E2=
=80=99d)
> looks in this direction (and so do I).
>
> Regards,
> Nadav


--=20
Best Regards
Masahiro Yamada