[Libre-soc-bugs] [Bug 550] binutils support needed for svp64

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=550

--- Comment #70 from dmitry.selyutin at 3mdeb.com ---
(In reply to Luke Kenneth Casson Leighton from comment #69)
> (In reply to dmitry.selyutin from comment #68)
> 
> > OK, so we both agree that there must be at least _some_ array, even if this
> > array contains only uint64_t (I doubt, though: there must be at least
> > something which binds svp64 entry and ppc opcode, be it instruction name or
> > opcode itself).
> 
> errr oh yes, you're right: instruction name (as an ascii string) followed
> by uint64_t.  doh.

It also looks like that at least a pair of two uint32_t is needed to represent
opcode plus mask (cf. opcode in extra.csv).

> and, also, avoid the CPU cycles of double hashtree lookups, which has
> to be taken into consideration due to the sheer overwhelming size of
> executables these days.
> ...
> plus, by doing a LEFT-JOIN-like merge, that is only done once [and is
> pretty optimal as long as the two lists are pre-sorted], whereas double
> hashtable lookups are on every single instruction.

Ah, OK, I got the rationale. Well, for this particular case, we could've even
searched entries in a sorted array, since count of entries is quite limited
(cache-friendly 283 entries; makes even more sense to keep these compact).
However, since we have to lookup PPC entry anyway, regardless of whether we
deal with SVP64 or not, I think saving one lookup is totally reasonable. I'll
need to consult you when I start doing this, since I've never used SQL, but I
think I get the overall idea. Thanks for the tip!

-- 
You are receiving this mail because:
You are on the CC list for the bug.