This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING for PowerPC: Add msingle-pic-base option


Michael Meissner <meissner@linux.vnet.ibm.com> wrote on 2010/11/22 22:48:52:
>
> On Mon, Nov 22, 2010 at 10:32:10PM +0100, Joakim Tjernlund wrote:
> > Michael Meissner <meissner@linux.vnet.ibm.com> wrote on 2010/11/22 18:43:26:
> > >
> > > On Wed, Nov 03, 2010 at 11:38:04AM +0100, Joakim Tjernlund wrote:
> > > >
> > > > http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01677.html
> > >
> > > Please don't use a Mask in the rs6000.opt file, as we are out of bits (or
> > > nearly out of ISA bits).  Instead you should use Var to use a separate
> > > variable.  This way it won't cause extra pressure on the ISA bits, and possibly
> > > break some ports.
> >
> > hmm, I just copied the ARM impl. for this option. I could switch to Var if
> > I can figure out how Var works. Got any hints how I would add msingle-base-pic
> > using Var?
>
> For example, when I added -mfriz, I used this line:
>
> mfriz
> Target Report Var(TARGET_FRIZ) Init(-1) Save
> Under -ffast-math, generate a FRIZ instruction for (double)(long long) conversions
>
> The first line gives the option (i.e. -mfriz).
>
> The second line gives the various attributes, which are documented in the
> options section of the internal manual (doc/options.texi is the raw file that
> is formated via texinfo to make the manual).  In this particular case:
>
>     Target   -- Option is a target option
>     Report   -- Report option with --help
>     Var(...)   -- Declare ... as a variable instead of a mask
>     Init(...)   -- Initialize variable to ...
>     Save   -- Copy variable to the target specific save area for each
>          function
>
> The third line gives the documentation.
>
> So, instead of TARGET_FRIZ becoming ((target_flags & MASK_FRIZ) != 0) which is
> what happens without the Var, it becomes a normal variable.

I see, this is all I need. Thanks a lot :)

>
> > >
> > > While this option isn't likely to be used in a target attribute, you probably
> > > should add a Save option, just in case.
> > >
> > > I didn't see any patches to doc/invoke.texi to document this new option.
> >
> > hmm, no. msingle-base-pic is mentioned there already though as this
> > option already exists for ARM.
>
> You still need to add a section to document it in the PowerPC options.  Each of
> the -m options are unique to a given target.  User's would not expect to look
> up a PowerPC option in the Arm section of the manual.  Yes, there are some
> options that have the same spelling as other target options, but you still need
> to duplicate the documentation in each target that provides the option.

OK, will have a look then.

>
> > >
> > > > and a mini ping for powerpc: Support -fpic too with mrelocatable
> > > >  http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02301.html
> > >
> > > I haven't looked at -mrelocatable in 10+ years, but the original motivation for
> > > it was it was added in the early days of the eABI compiler before -fpic was
> > > added to the PowerPC compiler, and a client needed a simple method of having
> > > his/her code relocated.  What would -fpic -mrelocatable do that that either
> > > -mrelocatable or -fpic alone already does not do?  If people are still using
> > > -mrelocatable, perhaps it is time to teach the embedded ports about doing full
> > > pic, and migrate to that.
> >
> > There is still a need for a simple way to relocate code. u-boot uses it
> > as it is small and efficient. However, -mrelocate always implies -fPIC and
> > that has a higher footprint. -mrelocatable is the only option that will
> > generate FIXUPS. Anyhow, this has already been dealt with so no need to
> > discuss that anymore.

side note, if gcc could sort the GOT so all entries needing fixups where
in one place, one would just need a pointer to that part of the got and
one could skip the separate fixup table.

>
> David Edelsohn will have to weigh in on whether it goes in or not, since he is
> the port maintainer.

He already did, it is in the gcc repo :)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]