Duncan,
I was wondering if you'd be open to making a change in the IR parser to accept and ignore 'metadata' keywords in the places they used to be required. My common workflow is to use a version of clang (from the last major release) to generate test IR fragments. Right now, this is not possible since IR generated by the previous released clang no longer parses with TOT.
I know we don't generally support forward serialization of IR, but in practice, it generally works for this type of usage. What do you think?
Philip
Duncan,
I was wondering if you'd be open to making a change in the IR parser to
accept and ignore 'metadata' keywords in the places they used to be
required. My common workflow is to use a version of clang (from the last
major release) to generate test IR fragments. Right now, this is not
possible since IR generated by the previous released clang no longer parses
with TOT.
How about going through bitcode, which AFAIK doesn't have that
problem? That is, assemble with the previous llvm-as, and disassemble
with ToT llvm-dis (or use as is.)
- Ahmed
Duncan,
I was wondering if you'd be open to making a change in the IR parser to
accept and ignore 'metadata' keywords in the places they used to be
required. My common workflow is to use a version of clang (from the last
major release) to generate test IR fragments. Right now, this is not
possible since IR generated by the previous released clang no longer parses
with TOT.
How about going through bitcode, which AFAIK doesn't have that
problem? That is, assemble with the previous llvm-as, and disassemble
with ToT llvm-dis (or use as is.)
This would certainly work. There's a number of possible workarounds. I'm not claiming this is any fundamental problem, only that it's slightly tedious and doesn't really cost us anything to fix.
(Think about a person new to llvm who runs into this. How are they going to react?)
Duncan,
I was wondering if you’d be open to making a change in the IR parser to
accept and ignore ‘metadata’ keywords in the places they used to be
required. My common workflow is to use a version of clang (from the last
major release) to generate test IR fragments. Right now, this is not
possible since IR generated by the previous released clang no longer parses
with TOT.
How about going through bitcode, which AFAIK doesn’t have that
problem? That is, assemble with the previous llvm-as, and disassemble
with ToT llvm-dis (or use as is.)
This would certainly work. There’s a number of possible workarounds.
I’m not claiming this is any fundamental problem, only that it’s
slightly tedious and doesn’t really cost us anything to fix.
Except maintenance, possible bugs in the conversions, etc.
(Think about a person new to llvm who runs into this. How are they
going to react?)
LLVM has been pretty open about this sort of thing not being guaranteed. Also, very few people do a lot with the IR and most people doing development are using new tools.
-eric
I don't like the precedent this would set. There was some discussion
on the list already about this, starting with [1].
[1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079941.html
[2]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079958.html
I think you'd be better off generating testcases from ToT, or outputting
to bitcode and using `llvm-dis` from ToT.