[PATCH] [mips] Don't use odd-numbered single precision registers for fastcc calling convention if -mno-odd-spreg is used.

[Daniel Sanders]

>>! In D4682#8, @sstankovic wrote:
> I tried $[[F0:f[0-9]*[02468]+]] but it also doesn't work. It seems that problem is related to using DAG in check lines. I removed DAG from the last 3 lines, used $[[F0:f[0-9]*[02468]]] pattern and the test passes.

I've explained the current problem below. To be clear, I think you are ok to commit as-is. If it's possible to follow-up to make the test more robust then we should do so. Unique-ing the output instructions using different offsets is a good way to do this but I've found cases before where it's not sufficient (one of the calling convention tests has the same problem).

================
Comment at: test/CodeGen/Mips/fastcc.ll:300-302
@@ +299,5 @@
+; NOODDSPREG-DAG:    lw $[[R0:[0-9]+]], %got(gfa10)($[[GP]])
+; For some reason the expression $[[F0:f[0-9]*[02468]]] for even float registers
+; doesn't work here (it works below in callee2), so I just enumerated the
+; registers.
+; NOODDSPREG-DAG:    lwc1 $[[F0:f20|f22|f24|f26|f28|f30]], 0($[[R0]])
----------------
Daniel Sanders wrote:
> It's because FileCheck scans ahead for ']]' which leaves the pattern as 'f[0-9]*[02468'. I usually work around it using a '+' like so:
>   $[[F0:f[0-9]*[02468]+]]
> I can't explain why the other one works though. Triple ']' has never worked correctly for me.
I think I see why this didn't work. It seems that the directive on line 303 is matching the first lwc1 in the code below:
        lw      $1, %got(gfa8)($gp)
        lwc1    $f16, 0($1)
        ...
        lw      $1, %got(gfa10)($gp)
        lwc1    $f20, 0($1)
The reason I think this happens is that IIRC, all the *-DAG directives start their search from the same point (the directive on line 273). There's nothing making the lines unique so line 295 and line 303 match in the same place. This leaves F0 set to the wrong register, line 304 fails to match, and the test is reported to fail.

There are two solutions to this. The first is make each line unique using different offsets into an array instead of using multiple global variables. The second is the way you've done it: Use something other than *-DAG to advance the current position past the unintended match.

If the above is correct, then I'm inclined to think that FileCheck ought to be accounting for the topography earlier. In particular, variable uses ought to start matching from the end of the directive containing the definition (instead of from the end of the previous non-*-DAG directive). However, changing that is likely to be hard and it's difficult to say whether there are tests depending on the current behaviour or not.

http://reviews.llvm.org/D4682