Problem when defining new mips insns

[Pontus Lidman]

Roger Sayle <roger@eyesopen.com> 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

-- 
Pontus Lidman, pontus@lysator.liu.se, Software Engineer
No matter how cynical you get, it's impossible to keep up.
Scene: www.dc-s.com | MUD: tyme.envy.com 6969 | irc: irc.quakenet.eu.org