public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Peter Bergner <bergner@vnet.ibm.com>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: Remove E6500 insns from PPC_OPCODE_ALTIVEC2
Date: Mon, 10 Apr 2017 16:40:00 -0000	[thread overview]
Message-ID: <56bd3181-3748-7b60-4d05-cf734d88ba4b@vnet.ibm.com> (raw)
In-Reply-To: <20170408010756.GY16711@bubble.grove.modra.org>

On 4/7/17 8:07 PM, Alan Modra wrote:
> On another subject, I'd like your opinion on removing -[mM]htm options
> from gas and the disassembler.  I think now that it was a mistake to
> add them in the first place (and every other use of .sticky except for
> -mall and -mraw).  I would have liked to remove -[mM]vsx too, but
> "gcc -mvsx" passes on -mvsx to gas, and has done so for quite some
> time.  So -mvsx looks impossible to remove without breaking gcc.
> "gcc -mhtm" on the other hand, passes -mpower8 to gas, and it's been
> that way since -mhtm was added to gcc.

I was going to say you cannot remove it, because we use gcc's -mhtm
option to build LIBITM, but if we're passing -mpower8 to the assembler
when using gcc's -mhtm option, then I guess it's ok if there are no
users outside of binutils that use the -mhtm gas option (kernel?).
I'm sure I was going to have gcc pass -mhtm to gas instead of -mpower8,
but since I didn't , I guess this is ok.

I agree, we're stuck keeping -mvsx.



> Also, I'm intending to remove some of PPC_OPCODE_*, for instance
> PPC_OPCODE_ALTIVEC2 can disappear and we then use
> 
> #define PPCVEC2 (PPC_OPCODE_POWER8 | PPC_OPCODE_E6500)
> #define PPCVEC3 PPC_OPCODE_POWER9
> 
> in opcodes/ppc-opc.c which should improve gas opcode checks vs. cpu.
> Dodgy gcc output would then be found at compile time rather than run
> time 

Looking at how PPCVEC2 and PPCVEC3 are used, yeah, that should work.
I also like that we can reclaim some bits in the cpu mask, since
there are only a limited amount of them.

Can we also get rid of PPC_OPCODE_HTM and use...?

#define PPCHTM PPC_OPCODE_POWER8


> (assuming -many is removed from powerpc gcc, another little
> project of mine).

I never liked gcc always passing -many to the assembler, so if
you can remove it, I'm all for it!

Peter



  reply	other threads:[~2017-04-10 16:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07  9:53 Alan Modra
2017-04-07 12:59 ` Peter Bergner
2017-04-08  1:08   ` Alan Modra
2017-04-10 16:40     ` Peter Bergner [this message]
2017-04-10 22:22       ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56bd3181-3748-7b60-4d05-cf734d88ba4b@vnet.ibm.com \
    --to=bergner@vnet.ibm.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).