On Wed, Aug 06, 2025 at 01:32:07PM +0000, Thomas de Bock wrote:
> Apologies if I was unclear or misunderstand, I believe that's exactly what I
> am
> doing right now. I change the !='s' to =='s' and switch their true with their
> false
> edge, from there we can simply find the equality edge by finding the TRUE
> edge.
> If this is an unwelcome change however, it can easily be done without changing
> the operator.
Not modifying the comparisons and just taking it into account during pattern
matching would be greatly appreciated I think.
> > "The memcmp() function returns an integer less than, equal to, or greater
> > than zero if the first n bytes of s1 is found, respectively, to be less
> > than, to match, or be greater than the first n bytes of s2.
>
> > For a nonzero return value, the sign is determined by the sign of the
> > difference between the first pair of bytes (interpreted as unsigned char)
> > that differ in s1 and s2."
>
> Sorry for my wording, that is not the only thing memcmp gives us, but it
> does not give us information regarding which fields mismatched. So we cannot
> deal with (after !='s are converted to =='s) blocks where not all blocks in
> a chain have the same node as their (eventual, possibly through fallthru's)
> FALSE edge's destination, is what I was trying to say.
That shouldn't matter, unless you want to pattern recognize random orders
of the comparisons (and only verify all bits in the range are compared).
For <=> it needs to bbe sequential like memcmp will be, i.e. first compare
bytes with the smallest index, then the one above it etc.
Also, note some comparisons could be using COMPONENT_REFs, so a->b.c
kind of form, while others in the same chain could be MEM_REFs [a, 28].
For what exactly is read one should use e.g. get_inner_reference
to find if all the loads are from the same (2) bases at the right offsets.
Punt for volatiles, punt or be very careful for reversep, etc.
Note, for both == and != or even <=> some comparisons could have accesses
using one base on the lhs and the other on rhs and in others have them
swapped. It can also handle bitfields, for ==/!= all that matters is that
all bits are compared and the block starts and ends at a byte boundary.
For <=> it needs the right ordering and for non-unsigned char accesses
little endian.
Jakub
