[llvm] r212643 - Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.
peter at pcc.me.uk
Wed Jul 9 16:42:37 PDT 2014
On Wed, Jul 09, 2014 at 04:15:42PM -0700, Alexey Samsonov wrote:
> On Wed, Jul 9, 2014 at 1:42 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> > 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.
> > Okay.
> > 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.
> No, I don't currently plan refactoring of SpecialCaseList, instead I'm
> going change
> the behavior of SanitizerBlacklist. Literal representation of
> metacharacters (except for *)
> sounds like a good idea - documentation refers to special case list entries
> as "wildcard
> expressions", not "regular expressions", so it would be weird to force
> users to escape
> characters on their own.
The patterns are referred to as "regular expressions" here, with examples
that use RE syntax and specifically refer to the patterns as being EREs:
The examples don't seem particularly compelling to me. If not bound by
compatibility constraints, I would make '*' the only recognized metacharacter.
Maybe we should add support to SpecialCaseList for a "version 2" of the
format which only supports '*'?
> But, yes, let's make this change affect DFSan only
> for now,
> just add an extra parameter to SpecialCaseList factory to specify if it
> needs to escape
> metachars when parsing the file.
OK, sounds good.
More information about the llvm-commits