On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov
<kyrylo.tkac...@foss.arm.com> wrote:
>
> Hi Christophe,
>
> On 11/18/19 9:00 AM, Christophe Lyon wrote:
> > On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
> > <christophe.l...@linaro.org> wrote:
> > >
> > > On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
> > > <richard.earns...@arm.com> wrote:
> > > >
> > > > On 18/10/2019 14:18, Christophe Lyon wrote:
> > > > > +      bool not_supported = arm_arch_notm || flag_pic ||
> > TARGET_NEON;
> > > > >
> > > >
> > > > This is a poor name in the context of the function as a whole.  What's
> > > > not supported.  Please think of a better name so that I have some idea
> > > > what the intention is.
> > >
> > > That's to keep most of the code common when checking if -mpure-code
> > > and -mslow-flash-data are supported.
> > > These 3 cases are common to the two compilation flags, and
> > > -mslow-flash-data still needs to check TARGET_HAVE_MOVT in addition.
> > >
> > > Would "common_unsupported_modes" work better for you?
> > > Or I can duplicate the "arm_arch_notm || flag_pic || TARGET_NEON" in
> > > the two tests.
> > >
> >
> > Hi,
> >
> > Here is an updated version, using "common_unsupported_modes" instead
> > of "not_supported", and fixing the typo reported by Kyrill.
> > The ChangeLog is still the same.
> >
> > OK?
>
>
> The name looks ok to me. Richard had a concern about Armv8-M Baseline,
> but I do see it being supported as you pointed out.
>
> So I believe all the concerns are addressed.
OK, thanks!

>
> Thus the code is ok. However, please also updated the documentation for
> -mpure-code in invoke.texi (it currently states that a MOVT instruction
> is needed).
>
I didn't think about this :(
It currently says: "This option is only available when generating
non-pic code for M-profile targets with the MOVT instruction."

I suggest to remove the "with the MOVT instruction" part. Is that OK
if I commit my patch and this doc change?

Christophe

> Thanks,
>
> Kyrill
>
>
>
> >
> > Thanks,
> >
> > Christophe
> >
> > > Thanks,
> > >
> > > Christophe
> > >
> > > >
> > > > R.

Reply via email to