[all-commits] [llvm/llvm-project] 89d8df: CodeGen, IR: Add target-{cpu, features} attributes ...

pcc via All-commits all-commits at lists.llvm.org
Tue Jun 25 20:39:40 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 89d8df12015ac3440190d372a8d439614027dc2c
      https://github.com/llvm/llvm-project/commit/89d8df12015ac3440190d372a8d439614027dc2c
  Author: pcc <peter at pcc.me.uk>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
    M clang/lib/CodeGen/CodeGenAction.cpp
    M clang/test/CodeGen/asan-frame-pointer.cpp
    M clang/test/CodeGen/asan-globals.cpp
    A clang/test/CodeGen/coverage-target-attr.c
    M clang/test/CodeGen/sanitize-metadata-nosanitize.c
    M llvm/include/llvm/IR/Function.h
    M llvm/include/llvm/IR/LLVMContext.h
    M llvm/lib/IR/Function.cpp
    M llvm/lib/IR/LLVMContext.cpp
    M llvm/lib/IR/LLVMContextImpl.h

  Log Message:
  -----------
  CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr().

Functions created with createWithDefaultAttr() need to have the
correct target-{cpu,features} attributes to avoid miscompilations
such as using the wrong relocation type to access globals (missing
tagged-globals feature), clobbering registers specified via -ffixed-*
(missing reserve-* feature), and so on.

There's already a number of attributes copied from the module flags
onto functions created by createWithDefaultAttr(). I don't think
module flags are the right choice for the target attributes because
we don't need the conflict resolution logic between modules with
different target attributes, nor does it seem sensible to add it:
there's no unambiguously "correct" set of target attributes when
merging two modules with different attributes, and nor should there
be; it's perfectly valid for two modules to be compiled with different
target attributes, that's the whole reason why they are per-function.

This also implies that it's unnecessary to serialize the attributes in
bitcode, which implies that they shouldn't be stored on the module. We
can also observe that for the most part, createWithDefaultAttr()
is called from compiler passes such as sanitizers, coverage and
profiling passes that are part of the compile time pipeline, not
the LTO pipeline. This hints at a solution: we need to store the
attributes in a non-serialized location associated with the ambient
compilation context. Therefore in this patch I elected to store the
attributes on the LLVMContext.

There are calls to createWithDefaultAttr() in the NVPTX and AMDGPU
backends, and those calls would happen at LTO time. For those callers,
the bug still potentially exists and it would be necessary to refactor
them to create the functions at compile time if this issue is relevant
on those platforms.

Fixes #93633.

Reviewers: fmayer, MaskRay, eugenis

Reviewed By: MaskRay

Pull Request: https://github.com/llvm/llvm-project/pull/96721



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list