Hacker News new | past | comments | ask | show | jobs | submit login
Revec: Program Rejuvenation Through Revectorization (github.com/revec)
49 points by homarp on July 31, 2019 | hide | past | favorite | 5 comments

> 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)?

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.

Looks like an abandoned research project.

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).

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact