Closed robdockins closed 5 years ago
I wonder if the right approach is to parameterize the pretty-printer with version information?
Alternately, we could say that we support 3.7 onwards, but I'm not sure how reasonable that is...
I think it would be better to parameterize things, or to have different printing modules that target different LLVM versions. I'm not sure which would be easier in the end.
My vote would be for a version parameter as well. As the llvm textual IR is not guaranteed to be stable, and might change with every version.
I've started work on parameterizing the pretty-printer, and providing different running functions that correspond to LLVM versions. So far, I've only defined runners for 3.5, 3.6, and 3.7.
@elliottt Are you planning a "do the right thing" function that, perhaps through trial and error, will decode the bytecode regardless of the version?
That's the plan, at least back to 3.0, which shouldn't take too much effort. That might change with 4.0, depending on how much they change it.
On Tue, Sep 27, 2016, 17:57 Thomas M. DuBuisson notifications@github.com wrote:
@elliottt https://github.com/elliottt Are you planning a "do the right thing" function that, perhaps through trial and error, will decode the bytecode regardless of the version?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/elliottt/llvm-pretty/issues/5#issuecomment-250042993, or mute the thread https://github.com/notifications/unsubscribe-auth/AABYtKNZLPzrWcyr-dIkOiAWFhlgwULgks5qubtzgaJpZM4I7M-- .
Can we close this?
I suppose before closing this we should handle some of the warnings. For example, llvm will warn if we omit a target triple such as:
target triple = "x86_64-pc-linux-gnu"
Progress on target triples is tracked on #21.
I've started tracking LLVM 6 compatibility here: https://github.com/elliottt/llvm-pretty/projects/1. I think it'll be easiest if we open issues as they arise, noting the appropriate LLVM version. Also, I think there's decent support for LLVM 3.7 now.
The pretty printer produces LLVM syntax that does not parse in LLVM 3.7 and later. For example, the syntax of the load instruction changed in an incompatible way (sigh):
See http://llvm.org/releases/3.5.0/docs/LangRef.html#id157 (the load syntax for LLVM 3.5) vs. http://llvm.org/releases/3.7.0/docs/LangRef.html#id172 (the load syntax for LLVM 3.7).
I would not be surprised if there are other, similar incompatiblities.