This is the mail archive of the
mailing list for the GCC project.
Re: PING for PowerPC: Add msingle-pic-base option
Michael Meissner <firstname.lastname@example.org> wrote on 2010/11/22 22:48:52:
> On Mon, Nov 22, 2010 at 10:32:10PM +0100, Joakim Tjernlund wrote:
> > Michael Meissner <email@example.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:
> 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
> 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 :)