https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #1)
> (In reply to Alexandre Oliva from comment #0)
> > - TARGET_64BIT seems to imply TARGET_POWERPC64, but TARGET_POWERPC64 doesn't
> > imply TARGET_64BIT
> I'll answer this first, since it affects your observations and questions.
> Yes, TARGET_64BIT implies TARGET_POWERPC64 and yes, TARGET_POWERPC64 does
> not imply TARGET_64BIT. Confusing I know!
TARGET_64BIT is kind of generic (every target defines it itself, but many do,
and the meaning is the same always: are pointers 64-bit, essentially).
TARGET_POWERPC64 means the target supports 64-bit instructions. This is true
for all CPUs that *can* run SF=1, 64-bit addressing enabled. You can run all
these instructions when SF=0 as well, and most of those instructions make sense
somewhat as well. When running in 32-bit mode the contents of the top half
of the registers is not guaranteed, can be killed at any point really, but
that is not often a problem, many insns have a useful effect using only the
low half of register contents!
> TARGET_64BIT (ie, -m64) tells us whether the binary we are creating will be
> running in 64-bit mode or not.
Whether the ABI is a 64-bit ABI. Yes.
> TARGET_POWERPC64 (-mpowerpc64) tells us
> whether we can emit 64-bit ISA instructions.
Long long long ago it was a special category in the PEM even, but nowadays
pretty much every CPU supports it of course :-)
> The confusion is that most
> 64-bit ISA instructions execute just fine in 32-bit mode (ie, -m32) _when_
> they are run on 64-bit hardware.
Yes. The registers are 64-bit (on 64-bit hardware) anyway, and most OSes
save all contents always. But in GCC we do not depend on that. On older Linux
the top half of register contents could be vandalised in some cases, for
example.
> We do support and there are specialized
> use cases for -m32 -mpower64 compiles, which is when TARGET_64BIT can be
> false and TARGET_POWERPC64 true.
"Specialised"... It is the default for most people, anyone using any recent
-mcpu=!
> > cmpeqb's conditions are TARGET_P9_MISC && TARGET_64BIT,
> This is correct, as the cmpeqb ISA description states that the instruction
> has UB in 32-bit mode. This is unlike many of our 64-bit load and store
> instructions which do work in 32-bit mode, so they're gated by
> TARGET_POWERPC64.
Yup. Instructions that have output bits not in the top 32 bits of a GPR that
depend on the top 32 bits of GPRs need -m64.
> > but the conditions that enable the expansion of __builtin_scalar_byte_in_set
> > are those of [power9-64], namely TARGET_MODULE && TARGET_POWERPC64.
> I believe this is a bug and this and the other [power*-64] tests should be
> using TARGET_64BIT instead of TARGET_POWERPC64.
Sounds like it yes.
> > On a powerpc-elf standard build, TARGET_POWERPC64 is enabled, but
> > TARGET_64BIT isn't, and so gcc.target/powerpc/byte-in-set-2.c fails
> > to compile with an ICE (instruction not recognized) instead of the
> > expected error.
>
> That powerpc-elf enables TARGET_POWERPC64 smells like a bug to me as well,
> but not knowing who/what uses that target triplet, I cannot say for certain.
It should not (and does not!) be enabled by default, no. But if you use -mcpu=
or similar chances are you get TARGET_POWERPC64 enabled, as you should.
> Segher & Mike, do you agree that powerpc-elf should not be enabling
> TARGET_POWERPC64 by default? This does not happen on a powerpc-linux build.
All our subtargets (OS targets) have their own default CPUs as well, this might
matter here?
