[Bug rtl-optimization/59461] missed zero-extension elimination in the combiner

matthew.fortune at imgtec dot com gcc-bugzilla@gcc.gnu.org
Fri Jan 13 09:40:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59461

--- Comment #10 from Matthew Fortune <matthew.fortune at imgtec dot com> ---
(In reply to Eric Botcazou from comment #9)
> > This is a notoriously hard topic to address. All instructions affect the
> > full 64-bit register including those that do 32-bit arithmetic i.e. they
> > will set/clear the upper bits to replicate bit-31.
> 
> So there are different 32-bit and 64-bit 'add' instructions for example? 
> That might nevertheless be OK for WORD_REGISTER_OPERATIONS.

Yes. But logical operations are the same machine instructions regardless of
whether it is being used for a 64-bit logical op or 32-bit logical op.

> > In terms of instruction definition we therefore have instructions that
> > operate on DImode and instructions that operate on SImode. The SImode
> > instructions just don't need to worry about what is happening with the upper
> > bits.
> 
> Likewise for SPARC, which is WORD_REGISTER_OPERATIONS too, but doesn't care
> about the upper bits in 32-bit mode and has a single 'add' instruction (but
> maintains 32-bit _and_ 64-bit condition codes for every instruction).

So are the upper bits for SPARC completely undefined? That would then be the
major distinction between MIPS and SPARC. The upper bits are defined for MIPS

> > I don't know if any of that subtlety affects this yet.
> 
> Bugs in the nonzero_bits machinery are not to be ruled out either.  I'm
> willing to help of course but I don't have access to MIPS64 hardware.

I'm yet to even narrow down to an object file affected owing to the bug only
showing in stage2 build so far.

Thanks for the offer of help, I'll add more when I find it.


More information about the Gcc-bugs mailing list