abrown opened PR #2819 from inst-format-3
to main
:
This introduces the mechanism for encoding EVEX instructions to the new backend (ported with slight changes from the old) and then uses it to improve the lowering of
iabs.i64x2
from 5 instructions to 1 instruction (i.e.VPABSQ
).
abrown requested cfallin for a review on PR #2819.
abrown requested cfallin and bnjbvr for a review on PR #2819.
abrown requested cfallin, bnjbvr and jlb6740 for a review on PR #2819.
abrown updated PR #2819 from inst-format-3
to main
.
abrown has marked PR #2819 as ready for review.
abrown submitted PR Review.
abrown created PR Review Comment:
I wish there were a way to avoid this here and instead specify it up above when necessary--suggestions welcome because I can't think of a great way to do this without rewriting this entire file.
abrown updated PR #2819 from inst-format-3
to main
.
bnjbvr submitted PR Review.
bnjbvr submitted PR Review.
bnjbvr created PR Review Comment:
since
value <= mask
andmask
is all ones, we don't need thevalue & mask
here and could just usevalue
bnjbvr created PR Review Comment:
nit:
followed
bnjbvr created PR Review Comment:
So the way it works right now is that it goes from the
RealReg
hardware encoding into an u8 then into thisRegister
structure. Could instead the methods takingRegister
take aRealReg
instead?
bnjbvr created PR Review Comment:
Isn't there already another
CodeSink
trait somewhere in this crate too? I wonder if we could avoid this one, to reduce the number of concepts, and just read out of theMachBuffer
internal vector, for testing purposes?
bnjbvr created PR Review Comment:
Instead of having a single array with all the testing tuples, we could have several ones, one for each Flag combination we'd like to test. Then we could refactor this function so that it takes
flags
from a parameter and an array of test tuples, or something like this?
bnjbvr created PR Review Comment:
Also, maybe not something to worry too much about, since there's no actual instruction selection test here. What was your concern?
abrown submitted PR Review.
abrown created PR Review Comment:
Yes, here but as you can see it would force this module to implement things it has no idea about and I wasn't too sure the old backend trait would be around forever. Also, I am trying to keep this module as dependency-free as possible so that in the future it could be used elsewhere--if I want to use this in the future to just encode instructions I won't want or need the additional
MachBuffer
methods and fields.
abrown edited PR Review Comment.
abrown created PR Review Comment:
I was under the impression that Rust will pare away those abstractions so I didn't worry too much about overhead. I am trying to keep this encoding code dependency-free (especially of external dependencies) so, like with
CodeSink
, I am using slightly different types/traits.
abrown submitted PR Review.
abrown submitted PR Review.
abrown created PR Review Comment:
Yeah, I guess that's true. It just looked weird to lump the AVX512 flag in with the baseline flags. Maybe in a follow-on PR I will try to factor out the "check these instructions" code so that I can do as you suggest above.
abrown updated PR #2819 from inst-format-3
to main
.
abrown updated PR #2819 from inst-format-3
to main
.
cfallin submitted PR Review.
cfallin created PR Review Comment:
Maybe we could name the trait something else --
ByteSink
or something?It might even make sense to do the factoring in the other direction -- split out
ByteSink
fromCodeSink
and make the former a constraint on the latter (trait CodeSink : ByteSink { ... }
with just the additional methods), but that's probably out-of-scope for this PR...
abrown updated PR #2819 from inst-format-3
to main
.
abrown merged PR #2819.
Last updated: Nov 22 2024 at 17:03 UTC