vsk added inline comments.
================ Comment at: packages/Python/lldbsuite/test/functionalities/target_var/globals.ll:1 +source_filename = "globals.c" +target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" ---------------- davide wrote: > vsk wrote: > > Should we check in bitcode instead? That might make it easier to avoid > > breakage when the textual IR format changes. > But also will be more painful to regenerate in case, e.g. add a verifier > check where this breaks. > I think it's a tradeoff anyway, I and Adrian discussed this briefly and > agreed this is a decent middle ground (on one extreme, one might check ASM > directly, but that seems even harder to handle). > > This is honestly based on my experience of having to regenerate broken > bitcode files, happy to be convinced otherwise if you have arguments :) (per an off-list discussion) I'm slightly biased towards preventing build breaks, but this sounds reasonable. A third option might be to check in both the bitcode (which is compiled) and the IR (which serves as a reference for regenerating the bitcode); that could address all/most of the concerns. Repository: rLLDB LLDB https://reviews.llvm.org/D52678 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
