FileCheck for instructions of indeterminate order?

To test some recent changes, I need to verify that seven instructions
are generated. However, the order of those instructions doesn't matter
(they are all independent loads from memory). Is there a way to tell
FileCheck to reset its scan position rather than assuming all CHECK:
instructions must be in the given order?

My initial version of the test was to use -O0, attempting to ensure that
the instructions weren't rescheduled. Although this gave a reproducible
order on my PowerPC machine, various buildbots of other architectures
produced codegen in a different order when cross-compiling to PowerPC.
Needless to say, the test is XFAILed until I can figure a way to test
this more safely.

All help appreciated!

Thanks,
Bill

N.B. I found the nondeterminacy at -O0 to be somewhat surprising...is
there some other option I need to avoid instruction reordering?

To test some recent changes, I need to verify that seven instructions
are generated. However, the order of those instructions doesn't matter
(they are all independent loads from memory). Is there a way to tell
FileCheck to reset its scan position rather than assuming all CHECK:
instructions must be in the given order?

See this thread:

Message-ID: <5049E695.2050508@codeaurora.org>

To test some recent changes, I need to verify that seven instructions
are generated. However, the order of those instructions doesn't matter
(they are all independent loads from memory). Is there a way to tell
FileCheck to reset its scan position rather than assuming all CHECK:
instructions must be in the given order?

My initial version of the test was to use -O0, attempting to ensure that
the instructions weren't rescheduled. Although this gave a reproducible
order on my PowerPC machine, various buildbots of other architectures
produced codegen in a different order when cross-compiling to PowerPC.
Needless to say, the test is XFAILed until I can figure a way to test
this more safely.

All help appreciated!

The order should be deterministic, even if arbitrary. The most common
source of problem is some code iterating over a hash.

Thanks,
Bill

Cheers,
Rafael