Inline pragmas for functions breaks Vivado HLS backend

[sgpthomas]

It seems like the INLINE pragma that we add to functions cause the synthesized circuit to be incorrect. Removing it causes the generated circuits to be correct. We need to figure out why this is the case.

[rachitnigam]

This is not sufficient to reproduce the bug. On a broader note, it seems hard in general to build upon a broken backend--we have to assume that the backend is correct for our semantics to be correct. A bug in the backend is not a bug in our compiler.

@sampsyo @sgpthomas thoughts?

[sampsyo]

Well, speaking purely philosophically and not about this specific case, I think it's a little less cut and dry for us than other compilers… because part of Dahlia's "value proposition" is in avoiding the "bad parts" of HLS. So wantonly producing incorrect hardware because the backend is broken is probably not the philosophy we want to embrace for all incorrectness. But on the other hand, at some point, we can't fix everything about the wobbliness of the backend…

[rachitnigam]

I thought the “avoiding bad parts” to be statically definable bad parts. HLS tools add new bugs every version. Trying to prevent those bug seems like a losing battle—we’d have to reverse engineer new bugs every version and the compiler would become a collection of ad hoc warnings.

On the other hand, the static behaviors rejected by the type system have a formal meaning and an explanation.

[sampsyo]

Yeah, always working around weird bugs might be infeasible. But I guess I'm just pointing out that the distinction between "weird bugs in this particular version of Vivado HLS" and "legitimately hard-to-implement hardware thing that VIvado HLS does poorly on" is a fuzzier line than it might seem. So, like, avoiding the "wrong" inlining pragma and finding the "right" one might be worth doing, for example.