-
Notifications
You must be signed in to change notification settings - Fork 39
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
Improve generated assembly for pflang filters #27
Labels
Comments
With the new backend from #95, the code looks like: return function(P,length)
if length < 34 then return false end
local var1 = cast("uint16_t*", P+12)[0]
if var1 == 8 then
if P[23] ~= 6 then return false end
if band(cast("uint16_t*", P+20)[0],65311) ~= 0 then return false end
local var7 = lshift(band(P[14],15),2)
local var8 = (var7 + 16)
if var8 > length then return false end
if cast("uint16_t*", P+(var7 + 14))[0] == 45845 then return true end
if (var7 + 18) > length then return false end
return cast("uint16_t*", P+var8)[0] == 45845
else
if length < 56 then return false end
if var1 ~= 56710 then return false end
local var24 = P[20]
if var24 == 6 then goto L22 end
do
if var24 ~= 44 then return false end
if P[54] == 6 then goto L22 end
return false
end
::L22::
if cast("uint16_t*", P+54)[0] == 45845 then return true end
if length < 58 then return false end
return cast("uint16_t*", P+56)[0] == 45845
end
end and there are three traces:
|
The assembly's still kinda trash to be honest. Oh well though, the performance is certainly fine though. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The generated assembly is not ideal. For example, for a loop reading packets from a pcap-format savefile and matching them against "tcp port 5555", we have the function:
Here is the IR trace of the loop:
Anything having type "num" in the loop is suboptimal -- all of the types can be proven to be integers. All the mucking about with tables and ffis and checks and such are also unnecessary. As such we see that the body of the loop has lots of memory accesses and floating point comparisons:
Sub-optimal. To fix this, we can hack on LuaJIT, or look to emit assembly ourselves. I would try the former before the latter, as it's not far off from what needs to happen.
The text was updated successfully, but these errors were encountered: