Problem when defining new mips insns

Pontus Lidman
Sun Oct 24 10:32:00 GMT 2004

Roger Sayle <> writes:


> My guess is that the problem might be caused by not defining instructions
> to load constants into TImode registers.  By introducing TImode, the GCC
> middle-end now realizes that it can implement IEEE floating point negation
> by just flipping the sign bit, i.e. by doing an XOR in TImode, presumably
> because sizeof(TImode) == sizeof(double).  Hence the middle-end, tries to
> expand "nega = (TImode)a ^ 0x8000000000000000".  It looks like the RTL
> expanders are unable to load this constant into a TImode register
> directly, and instead try to generate this constant via "1 << 63".
> I hope this provides enough of a clue to proceed from here.
> Perhaps LEGITIMATE_CONSTANT_P or force_const_mem?

Thank you for your reply. Perhaps I should have mentioned that it's on
mips64. TImode integers are 16 bytes, DImode ones are 8, so
sizeof(DImode)==sizeof(double). So I don't understand why it wants to
use TImode values in this case.

I had a look at LEGITIMATE_CONSTANT_P and the related functions
(mips_legitimize_const_move etc), and to extend those functions to
handle TImode values seems to be problematic since TImode is larger
than HOST_WIDE_INT (which is 8 bytes). I'd rather avoid that path for
integer constants if possible. I do support memory and register moves.

I understand now why the instruction is generated, but I don't
understand why it wants to use TImode, and I also don't understand why
it doesn't generate a library call for the shift. I thought
set_optab_libfunc() for ashl, ashr, lshr in TImode would make it
happen in this case also.

Best Regards,


Pontus Lidman,, Software Engineer
No matter how cynical you get, it's impossible to keep up.
Scene: | MUD: 6969 | irc:

More information about the Gcc mailing list