[llvm-dev] [LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag.

[Chirag Patel via llvm-dev]

I> f it makes the patches easier to review, one possibility is to leave scaffolding in place to support the old textual format while moving the actual flags around. Then in a follow-up patch, remove the support for the old > textual format and update the .ll tests.
> (Of course you would need to preserve support for the old .bc format.)
> 
>  think it is reasonable to assume that there are no mixed-mode .ll files; that is, if you see any of the old bool flags, the file is using the old format and not the new format.  So you would not need to worry about merging old-style flags and new-style flags.

 Thanks, I will split the patch, first move flags to spflags and then update the ll format.

- Chirag

-----Original Message-----
From: aprantl at apple.com <aprantl at apple.com> 
Sent: 21 February 2020 01:55
To: Djordje Todorovic <djordje.todorovic at rt-rk.com>
Cc: Chirag Patel <Chirag at raincode.com>; llvm-dev at lists.llvm.org; David Blaikie <dblaikie at gmail.com>; Paul Robinson <paul.robinson at sony.com>
Subject: Re: [llvm-dev] [LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag.



> On Feb 20, 2020, at 1:10 AM, Djordje Todorovic via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> AFAIK, there are no compatibility guarantees for textual LLVM IR, so we only need to support the bitcode auto-upgrade. So, that would be acceptable if there is motivation for doing that.

This is correct. We take binary bitcode upgrading seriously, and occasionally implement textual IR assembler upgrades out of sheer laziness, not wanting to update tons of tests. However, it is perfectly acceptable to update and cleanup lots of tests, if the commit message contains a sed/perl/python script to perform the update, so people can apply it on their downstream fork's testcases. This is particularly true if the upgrade mostly affects IR *input* (I expect this to be the case here) — we have too be more careful when updating CHECK-lines since they often not as amenable to upgrading via sed.

-- adrian