Ian Lance Taylor wrote: > Andrew Haley <aph@xxxxxxxxxx> writes: > >> Ian Lance Taylor wrote: >>> "Clem Taylor" <clem.taylor@xxxxxxxxx> writes: >>> >>>> I'm working on taking PowerPC VMX code that uses altivec intrinsics >>>> and rescheduling it with inline assembly. gcc is making some fairly >>>> bad scheduling choices in with the code, resulting in code that is >>>> running 4x slower then I was hoping for. I have a simplified version >>>> working, but with the real version gcc is failing with: "error: more >>>> than 30 operands in 'asm'". The code is using 28 vector registers and >>>> 6 serial registers. >>>> >>>> The code is a mixture of setup code in C and only the inner loop is in >>>> assembly, so it wouldn't be convenient to write this directly in >>>> assembly. Also, because the code is highly pipelined (to overcome the >>>> latency of the VMX floating point unit) it is a mess to split this up >>>> into multiple asm() statements. Beyond recompiling gcc with a larger >>>> operand count, is there a workaround for this problem? >>> Use fewer operands? Otherwise, no. It's a hard limit in gcc. >>> >>> Since you mention the number of registers you are using, note that >>> that only matters if they are inputs or outputs. If you need a >>> temporary register, just pick one, and add it the clobber list. But >>> if you really have that many inputs and outputs, then you are stuck. >> Isn't this trivially fixed by changing: >> >> /* Allow at least 30 operands for the sake of asm constructs. */ >> /* ??? We *really* ought to reorganize things such that there >> is no fixed upper bound. */ >> max_recog_operands = 29; /* We will add 1 later. */ >> max_dup_operands = 1; >> >> in genconfig.c ? > > Yes. Sorry for being confusing, I was answering the question "beyond > recompiling gcc...." I wonder if we could do something more sensible than simply using the constant 30. Perhaps some function of FIRST_PSEUDO_REGISTER, like FIRST_PSEUDO_REGISTER+20, or FIRST_PSEUDO_REGISTER*2 or even MAX (FIRST_PSEUDO_REGISTER, 29). This would at least solve the problem here. Andrew.
