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...." Ian
