Changes in vector.ll

61ec2148 - [DFSan] Remove -dfsan-args-abi support in favor of TLS.

Mon, 04 Oct 2021 20:31:18 +0000

[DFSan] Remove -dfsan-args-abi support in favor of TLS.ArgsABI was originally added in https://reviews.llvm.org/D965Current benchmarking does not show a significant difference.There is no need to maintain both ABIs.Reviewed By: pccDifferential Revision: https://reviews.llvm.org/D111097 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/DataFlowSanitizer/vector.ll

c6b5a25e - [dfsan] Replace dfs$ prefix with .dfsan suffix

Thu, 17 Jun 2021 21:55:05 +0000

[dfsan] Replace dfs$ prefix with .dfsan suffixThe current naming scheme adds the `dfs$` prefix to allDFSan-instrumented functions. This breaks mangling and prevents stacktrace printers and other tools from automatically demangling functionnames.This new naming scheme is mangling-compatible, with the `.dfsan`suffix being a vendor-specific suffix:https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-structureWith this fix, demangling utils would work out-of-the-box.Reviewed By: stephan.yichao.zhaoDifferential Revision: https://reviews.llvm.org/D104494 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/DataFlowSanitizer/vector.ll

5b4dda55 - [dfsan] Add full fast8 support

Fri, 04 Jun 2021 22:34:02 +0000

[dfsan] Add full fast8 supportComplete support for fast8:- amend shadow size and mapping in runtime- remove fast16 mode and -dfsan-fast-16-labels flag- remove legacy mode and make fast8 mode the default- remove dfsan-fast-8-labels flag- remove functions in dfsan interface only applicable to legacy- remove legacy-related instrumentation code and tests- update documentation.Reviewed By: stephan.yichao.zhao, browneeeDifferential Revision: https://reviews.llvm.org/D103745 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/DataFlowSanitizer/vector.ll

d10f173f - [dfsan] Add -dfsan-fast-8-labels flag

Tue, 16 Mar 2021 19:05:15 +0000

[dfsan] Add -dfsan-fast-8-labels flagThis is only adding support to the dfsan instrumentation pass but notto the runtime.Added more RUN lines for testing: for each instrumentation test thathad a -dfsan-fast-16-labels invocation, a new invocation was addedusing fast8.Reviewed By: stephan.yichao.zhaoDifferential Revision: https://reviews.llvm.org/D98734 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/DataFlowSanitizer/vector.ll

bd99f232 - [dfsan] Increase coverage of vector and select tests

Thu, 04 Mar 2021 02:03:04 +0000

[dfsan] Increase coverage of vector and select testsAdd more expectations in vector.ll and select.ll based on command-line option combinations.Also, remove hard-coded shadow width references to enable fast8 transition.Reviewed By: stephan.yichao.zhaoDifferential Revision: https://reviews.llvm.org/D97903 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/DataFlowSanitizer/vector.ll

ea981165 - [dfsan] Track field/index-level shadow values in variables

Mon, 23 Nov 2020 08:33:59 +0000

[dfsan] Track field/index-level shadow values in variables************** The problem*************See motivation examples in compiler-rt/test/dfsan/pair.cpp. The currentDFSan always uses a 16bit shadow value for a variable with any type bycombining all shadow values of all bytes of the variable. So it cannotdistinguish two fields of a struct: each field's shadow value equals thecombined shadow value of all fields. This introduces an overtaint issue.Consider a parsing function std::pair get_token(char* p);where p points to a buffer to parse, the returned pair includes the nexttoken and the pointer to the position in the buffer after the token.If the token is tainted, then both the returned pointer and int artainted. If the parser keeps on using get_token for the rest parsing,all the following outputs are tainted because of the tainted pointer.The CL is the first change to address the issue.*************************** The proposed improvement**************************Eventually all fields and indices have their own shadow values invariables and memory.For example, variables with type {i1, i3}, [2 x i1], {[2 x i4], i8},[2 x {i1, i1}] have shadow values with type {i16, i16}, [2 x i16],{[2 x i16], i16}, [2 x {i16, i16}] correspondingly; variables withprimary type still have shadow values i16.**************************** An potential implementation plan***************************The idea is to adopt the change incrementially.1) This CLSupport field-level accuracy at variables/args/ret in TLS mode,load/store/alloca still use combined shadow values.After the alloca promotion and SSA construction phases (>=-O1), weassume alloca and memory operations are reduced. So if structvariables do not relate to memory, their tracking is accurate atfield level.2) Support field-level accuracy at alloca3) Support field-level accuracy at load/storeThese two should make O0 and real memory access work.4) Support vector if necessary.5) Support Args mode if necessary.6) Support passing more accurate shadow values via custom functions ifnecessary.**************** About this CL.***************The CL did the following1) extended TLS arg/ret to work with aggregate types. This is similarto what MSan does.2) implemented how to map between an original type/value/zero-const toits shadow type/value/zero-const.3) extended (insert|extract)value to use field/index-level progagation.4) for other instructions, propagation rules are combining inputs by or.The CL converts between aggragate and primary shadow values at thecases.5) Custom function interfaces also need such a conversion becauseall existing custom functions use i16. It is unclear whether customefunctions need more accurate shadow propagation yet.6) Added test cases for aggregate type related cases.Reviewed-by: morehouseDifferential Revision: https://reviews.llvm.org/D92261 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/DataFlowSanitizer/vector.ll