[llvm] r212643 - Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.

Peter Collingbourne peter at pcc.me.uk
Wed Jul 9 13:42:42 PDT 2014

On Wed, Jul 09, 2014 at 07:40:09PM -0000, Alexey Samsonov wrote:
> Author: samsonov
> Date: Wed Jul  9 14:40:08 2014
> New Revision: 212643
> URL: http://llvm.org/viewvc/llvm-project?rev=212643&view=rev
> Log:
> Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.
> Turn llvm::SpecialCaseList into a simple class that parses text files in
> a specified format and knows nothing about LLVM IR. Move this class into
> LLVMSupport library. Implement two users of this class:
>   * DFSanABIList in DFSan instrumentation pass.
>   * SanitizerBlacklist in Clang CodeGen library.
> The latter will be modified to use actual source-level information from frontend
> (source file names) instead of unstable LLVM IR things (LLVM Module identifier).
> Remove dependency edge from ClangCodeGen/ClangDriver to LLVMTransformUtils.
> No functionality change.


Do you have any further refactoring planned for SpecialCaseList? One change
that I realised that I will need to make for DFSan is to change the semantics
for symbol names appearing in the special case list so that they are always
interpreted "literally", in order to allow symbol names that may contain
regex metacharacters to be added to the StringSet. Of course this would be
under a boolean argument somewhere so that the special case list semantics
for the other sanitizers aren't affected.

(The other solution to this problem that I thought of was to teach the tool
that builds the special case list to backslash-escape metacharacters and then
teach SpecialCaseList to try to unescape them, but then I realised that this
wouldn't work for the '*' character because we currently replace it with '.*'
which wouldn't be escaped correctly. Although I guess maybe we could say that
'\*' is treated like a literal '*' in the regex, meaning that one could write
'\\*' to match a literal '*'. But maybe so many levels of escaping would be
too confusing.)


More information about the llvm-commits mailing list