http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086
--- Comment #9 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #8) > > Do we have any documentation that states how many registers can be used in > > inline assembler for a particular arch and optset? "almost all" is not good > > enough for that. > > It is somewhat difficult question. Basically you are not supposed to use > any "fixed" > registers where fixed set of registers depends on compilation flags. For > example ESP is > always fixed, EBP is fixed depending on frame pointer elimination. > With PIC you need also EBP for GOT pointer and for DRAP you need another > register. > You need to leave enough registers so reload can load all additional operand > and addresses. > Things may have also changes with IRA - last time I looked into this was > with old reload. > > Vladimir, do you have idea about more precise description? It is very difficult to formulate this for all cases. For one alternative, I would say for any given class the number of allocatable hard regs of given class should be not less than max (non-output operands with a constraint register class intersecting given class, analogous for non-input operands). Early clobber operands are considered non-input and non-output. Operand modes should be taken into account too, e.g. an operand needs 2 regs. We cannot assume that a pseudo has an equivalent unallocatable hard reg expression. Still this description might not work when we have a subreg of bigger pseudo requiring at least 2 hard regs as sometimes we need to reload all pseudo. Also this formulation can be too strict when there are register and non-register constraint, e.g. memory. Several alternative can complicate the situation even more. As algorithms behind reload/LRA are too complicated and has a lot of details, the formulation will be too long. The simple formulation for all possible cases would be too constrained and not practical. Therefore nobody tried to write it down and we just have a fatal message 'can not reload'. > > > > If the user code that worked in 4.8 correctly is now broken for 4.9, we > > better > > need to respect the user and document it properly. > > Well, the problem is that precise set of constraints is exremely tied to > compiler internals (and it also changes from release to release, indeed). It > is overall problem of ASM statement extension in GCC, sadly. > >
