
Revec: Program Rejuvenation Through Revectorization - homarp
https://github.com/revec/llvm-revec
======
wyldfire
> Revec automatically finds equivalences between vector intrinsics across
> different instruction generations by enumerating all combinations.
> Equivalences are established through randomized and corner case testing

> We adopt a test case fuzzing approach for generating equivalences, with
> 18,000 randomly generated inputs and combinatorially generated corner-case
> inputs, inspired by test case generation in [6]. ... helped Revec to
> significantly reduce erroneous equivalences, and is consistent with the
> methodology in [6].

It sounds like an interesting approach. But how hard would it have been to ask
an expert to encode this information instead of empirically? And what about
instruction side effects, proc/coproc flags/modes etc? Does equivalence
consider those?

The llvm-revec fork has the pass, but does it also have the code to reproduce
the automated enumeration (and testing)?

------
CalChris
This paper was mentioned in the _RISC Is Fundamentally Unscalable_ post but
with respect to VLIW.

    
    
      The problem is that this is really fucking hard to
      compile, and that’s what Intel screwed up. Intel
      assumed that compilers in 2001 could extract the
      instruction-level parallelism necessary to make
      VLIW work, but in reality we’ve only very recently
      figured out how to reliably do that.
    

The ReVec article/repo doesn't mention VLIW as an application but I can see
parallels in the problem. If you compile for an 8-wide vector processor and
you get a 16-wide machine, you need to re-vectorize your code to take
advantage of the newly available width. That's similar if you change widen a
VLIW. Similar, not same. It seems an obvious _possible_ application but the
authors didn't mention it.

------
HelloNurse
Looks like an abandoned research project.

~~~
eslaught
I think abandoned is too strong of a word. Many research projects have an
explicit goal of building an MVP (and an explicit non-goal of doing anything
beyond that). The research project is only really "dead" when there are no
more questions to be asked. Even well-known professors some times have gaps of
years or decades when no apparent progress is being made, but may still pick
up the problem later and work on it (see e.g. the STOKE project and Alex
Aiken's previous superoptimization projects).

~~~
HelloNurse
I don't mean abandoned in a particularly negative sense, exactly because it's
normal for research project to be left behind as you describe.

But from the point of view of a potential user, this kind of software is
undeveloped, unsupported and rotting away (e.g. about two Clang versions
behind): probably useful as a prototype to plunder and reimplement, not as a
tool to get things done.

