-
Notifications
You must be signed in to change notification settings - Fork 881
Another optimization bug #38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Submitted by guy_harris Logged In: YES That change also introduced another bug:
generates
rather than
|
Submitted by guy_harris Logged In: YES Not a bug. "and" and "or" have equal precedence, and are left-associative, so that expression means
If the test against 0x86dd succeeds, and the test against 0x12345678 succeeds, then, if a subsequent test in the first sequence of expressions testing the 4-byte values fails, it'd fall through to the second sequence - but the first test in that sequence would fail, as ether[38:4] is known to be 0x12345678, and thus known not to be 0x11112222, so that second sequence would fail as well. That optimization ("static predicate prediction" in the BPF+ paper) is valid. However, the "other bug" still needs to be looked at. |
Submitted by guy_harris Logged In: YES The other bug is now fixed, probably as a result of some fixes I made where the optimizer didn't quite understand "jeq x". The code it generates is now
which, though not as optimal as it could be, is at least correct, i.e. it's testing against 0x12 in the second test. I have changes to fold
into
if the value of "x" isn't used in any successor blocks, although I might not check those in until the next libpcap release comes out - I'm more nervous about adding optimizations than about removing bogus optimizations.... |
Converted from SourceForge issue 860815, submitted by guy_harris
While looking at bug 766013, I tested with theexpression
That also generates bad code:
but only in the current CVS version - 0.7.x doesn't have that bug. It was introduced in revision 1.73 of
optimize.c - the change of
to
introduced it.
Unfortunately, removing that change causes "1 & len == 1" to generate
which, although correct, is a bit bogus, rather than generating
and causes "0 - len == 1" to generate
rather than
The text was updated successfully, but these errors were encountered: