Actually after your explanation below, a lot of things make total sense. Thanks, that cleared out several things to me.
However, there's a specific secondary reload question still bothering me: - I have seen cases where secondary reload is called and sri->icode != CODE_FOR_nothing. In which cases does this happen and should I touch it if the reload required no setting for sri->icode? Now, I will look at some code examples of using secondary reload with moves that _sometimes_ require a scratch register. Any tips on where to look? Cheers and once again thanks, Paulo Matos Ian Lance Taylor <i...@google.com> writes: > > First I'll note that in gcc the movMODE insn patterns are special. They > must be able to handle any simple move. So you can't use a separate > insn as above to move the instructions. > > Second, at reload time you can't generate a new insn which uses a > match_scratch, because reload runs after register allocation and it's > too late to create a new scratch register. You have to use a secondary > reload to get a scratch register at reload time. Now, reload does only > require the ability to load and store from memory, so for a lot of code > you can get away without using a secondary reload to transfer a value > from one register class to another. However, in my experience it is > always possible to write code that uses an unusual typecast to cause gcc > to want to move the value directly from a register in one class to a > register in another class. And then you need the secondary reload. > > Ian > -- PMatos
