Re: [Minios-devel] [UNIKRAFT PATCHv4 11/43] arch/arm64: Add processor optimization GCC flags for arm64

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Simon,

> -----Original Message-----
> From: Simon Kuenzer <simon.kuenzer@xxxxxxxxx>
> Sent: 2018年7月12日 17:56
> To: Julien Grall <Julien.Grall@xxxxxxx>; Wei Chen <Wei.Chen@xxxxxxx>; minios-
> devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 11/43] arch/arm64: Add processor
> optimization GCC flags for arm64
> 
> On 10.07.2018 14:28, Julien Grall wrote:
> > On 10/07/18 08:02, Wei Chen wrote:
> >> Hi Julien,
> > Hi Wei,
> >
> >>> -----Original Message-----
> >>> From: Julien Grall <julien.grall@xxxxxxx>
> >>> Sent: 2018年7月9日 18:26
> >>> To: Wei Chen <Wei.Chen@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
> >>> simon.kuenzer@xxxxxxxxx
> >>> Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> >>> Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 11/43] arch/arm64: Add
> >>> processor
> >>> optimization GCC flags for arm64
> >>>
> >>> On 09/07/18 10:17, Wei Chen wrote:
> >>>> Hi Julien,
> >>>
> >>> Hi,
> >>>
> >>>>> -----Original Message-----
> >>>>> From: Julien Grall <julien.grall@xxxxxxx>
> >>>>> Sent: 2018年7月8日 5:59
> >>>>> To: Wei Chen <Wei.Chen@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
> >>>>> simon.kuenzer@xxxxxxxxx
> >>>>> Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> >>>>> Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 11/43] arch/arm64: Add
> >>> processor
> >>>>> optimization GCC flags for arm64
> >>>>>
> >>>>> Hi Wei,
> >>>>>
> >>>>> On 07/06/2018 10:03 AM, Wei Chen wrote:
> >>>>>> We added serval arm64 CPU models in support list. In this patch,
> >>>>>
> >>>>> s/serval/several/
> >>>>>
> >>>>
> >>>> Oh, thanks again!
> >>>>
> >>>>> Cheers,
> >>>>>
> >>>>>> we check the GCC version and add optimization GCC flags for
> >>>>>> selected processor.
> >>>>>>
> >>>>>> Current supported arm64 CPU models:
> >>>>>> native, generic, cortex-a53, cortex-a57, cortex-a72, cortex-a73,
> >>>>>> cortex-a55 and cortex-a75.
> >>>>>>
> >>>>>> Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
> >>>>>> ---
> >>>>>>     arch/arm/arm64/Compiler.uk |  6 ++++++
> >>>>>>     arch/arm/arm64/Makefile.uk | 43
> >>>>>> ++++++++++++++++++++++++++++++++++++++
> >>>>>>     2 files changed, 49 insertions(+)
> >>>>>>     create mode 100644 arch/arm/arm64/Compiler.uk
> >>>>>>     create mode 100644 arch/arm/arm64/Makefile.uk
> >>>>>>
> >>>>>> diff --git a/arch/arm/arm64/Compiler.uk b/arch/arm/arm64/Compiler.uk
> >>>>>> new file mode 100644
> >>>>>> index 0000000..4572013
> >>>>>> --- /dev/null
> >>>>>> +++ b/arch/arm/arm64/Compiler.uk
> >>>>>> @@ -0,0 +1,6 @@
> >>>>>> +# set cross compile
> >>>>>> +ifeq ($(CONFIG_CROSS_COMPILE),)
> >>>>>> +ifneq ($(CONFIG_UK_ARCH),$(HOSTARCH))
> >>>>>> +    CONFIG_CROSS_COMPILE := aarch64-linux-gnu-
> >>>>>> +endif
> >>>>>> +endif
> >>>>>> diff --git a/arch/arm/arm64/Makefile.uk b/arch/arm/arm64/Makefile.uk
> >>>>>> new file mode 100644
> >>>>>> index 0000000..f6aeeac
> >>>>>> --- /dev/null
> >>>>>> +++ b/arch/arm/arm64/Makefile.uk
> >>>>>> @@ -0,0 +1,43 @@
> >>>>>> +ASFLAGS  += -D__ARM_64__
> >>>>>> +CFLAGS   += -D__ARM_64__ -fms-extensions
> >>>>>> +CXXFLAGS += -D__ARM_64__ -fms-extensions
> >>>>>
> >>>>> I would rather avoid to define yet another macro and re-use
> >>>>> __aarch64__
> >>>>> defined by the aarch64 compiler.
> >>>>
> >>>> It does make sense. But I am not sure if we keep __ARM_64__ here can
> >>>> improve
> >>>> the compatibility for other libraries. Because for internal
> >>>> libraries we can
> >>>> __aarch64__ uniformly. But for external libraries, we change them to
> >>> __aarch64__
> >>>> Easily.
> >>>
> >>> If other libraries are using __ARM_64__, then I would say go an fix your
> >>> libraries :). But I would expect most of them to use what's the compiler
> >>> provide.
> 
> Unfortunately, we did this mistake already with x86. It mainly came from
> code that we ported from Mini-OS (__X86_64__). Providing __ARM_64__ is
> now just being consistent with the status quo of Unikraft. On the other
> hand, the compiler provided macros (e.g., __aarch64__) are anyways there
> and should be best practice to use those. On the other hand, it does not
> hurt right now to keep __ARM_64__. I would say, if we want to get rid of
> this one, we should also get rid of the x86 ones but I would prefer this
> with another and independent patch series.
> 

I agree with you. We can keep these macros in current stage, and resend
a new patch series to do cleanup. 

> >>>
> >>
> >> Do you know from which version the GCC started to support __aarch64__
> >> macro
> >> by default? Or if we don't use GCC, does other compiler like LLVM still
> >> provide __aarch64__ macro?
> >
> 
> For now, we support only GCC. So it is fine to focus on this one. There
> are even other places in the code (e.g., nolibc) that rely on GCC
> definitions and would need to get fixed to support different compilers -
> especially when the one is not GCC compatible.
> 
> > I don't know which GCC version that started to support __aarch64__, but
> > I am ready to be this was there since the beginning as there are
> > counterpart for other architectures [1].
> >
> > Note that, we have been using that macro on Xen since that arm64 port
> > was added (5 years ago).
> >
> > For other compiler, while this is a GNU C extension, this is also at
> > least defined by Clang. I would not be surprised if other supports that
> > too as some headers will require to have different behavior depending on
> > the architecture.
> >
> > Cheers,
> >
> > [1] https://sourceforge.net/p/predef/wiki/Architectures/
> >
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel