On 5/20/25 8:39 PM, Li, Pan2 wrote:
Thanks Jeff.
So for the tests, why are we forcing matching of the assembly code for
the entire function? That must makes for a fragile test as we may
change various aspects of code generation over time.
If the point of the patch is to detect SAT_ADD in more cases, then the
better and more stable test is to verify the existence of SAT_ADD the
appropriate number of times in the .optimized dump.
IMHO we really don't want this kind of whole function assembly matching.
Pan, do you have any further comments here? Do you have strong opinions
on whether or not we want to be doing this kind of assembly output
testing or not?
Unlike vector we have vsadd for asm check, the scalar SAT_* will expand to
sorts of branchless codes.
So I add the function body check with no-schedule-insns. However, we have run
test for the same
scenarios which may also indicates the code-gen for SAT_ADD is correct.
Given that it is totally OK to drop that whole function check. How about keep
this series as is and I
can help to drop all the similar check of scalar in another thread?
Sure. I can live with that.
One of the things we probably want to do (but probably not that high
priority) is see how those sequences behave when zicond is turned on,
particularly since zicond got included in rva23.
Jeff
