Re: Problem with modyfying "addsi3" in machine description

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Expanders don't get constraints.

This sounds reasonable, but it was not stated in documentation.

Constraints in expanders are ignored.  This is documented.
To not confuse yourself or others, it's best not to write a
constraint.

SET should be VOIDmode, not SImode.

Ok, but why? I saw in few places (I'm almost sure event in official
GCC sources), that SET was used with SImode. Why it's so important?

Parts of the compiler might depend on it being VOIDmode always.
Yes, some targets get this wrong in places.

Use emit_move_insn :-)

I don't think it works. You still have the problem with offsets during
reload.  addsi3 is special, I think you need const_int offsets.
Otherwise spill code generation cannot work.

But what's so special about addsi3? For mulsi3 GCC is able to easily
change strategy and move immediate to register itself. Why doesn't it
work for addsi3 too? What "problem with offset during reload" actually
means?

GCC does the same thing with addsi3 as with mulsi3, _during expand_.
Reload however can create new addsi3 instructions out of thin air.
For example, if it wants to use some stack slot but it cannot access
it directly, it will compute the address of the stack slot into a
register: reg := sp+offset.  You need to be able to handle those
additions (well, some of them; at least the addsi2 things it tries
if you fail the addsi3 attempts).


Segher



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux