Modern optimizing compilers are already effective black boxes with massive "surface area complexity" that fail in strange ways and have bugs. That they have heu

Modern optimizing compilers are already effective black boxes with massive "surface area complexity" that fail in strange ways and have bugs. That they have heuristics written by humans doesn't necessarily mean they're explicable. None of that is new, honestly. You can find lots of bugs with already existing tools. The paper in question also uses DL for two things that have nothing to do with optimization, benchmark generation and fuzzing (which actually make existing compilers more robust), and the third technique which does learn optimization heuristics (between domains, even!) but it comes across as trivially deterministic. There is nothing to suggest that, say, deep learning cost models for a compiler will "magically generate invalid code" anymore than a compiler today already will. Furthermore, in this case the model isn't doing semantic translation between the input domain and output domain, it's rather answering queries like "is this better on a GPU or CPU" or "What is the best granularity to do this parallel task" i.e. it is constrained to a problem that is highly dimensional and variable, but in a sense has no impact on the outward semantics. This is how many such approaches work: they do not use models to "generate semantically equivalent results", but instead use them to replace existing oracles that answer questions a compiler already had to ask: "Is representation A cheaper than representation B, in this context?" is a very different problem than "Magically generate programs equivalent to A." The question is then whether your hand-written oracle is better than a machine learned one. The problem you're imagining, I suspect, is that the system will hit strange "performance cliffs" where one tiny tweak to the source will magically tank your performance, similar to adversarial approaches. But this is already the case today; writing highly performance sensitive code is largely a dance with the devil and you have to be working in tandem with the compiler constantly. On the other hand, "high level optimization" like choosing workload granularity is still understood rather poorly, I think. I don't think it's immediately clear if the current way we do things is better or not. Compilers make many, many individual decisions that are "locally optimal" without necessarily getting global optimums. Much of this can be said of SQL optimizers, which have very similar problems and followed a similar history (complex, hand-written heuristic-based optimizers vs cost models combined with searching the problem space.) In a similar vein I suspect an approach like this could be very powerful when combined with designs like equality saturation, which would effectively make a modern compiler look like an advanced, global cost optimizer in a SQL database. I suggest you try actually reading the paper. It's pretty interesting.