History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 476 – 500 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 52bcd691 23-Sep-2020 Yaxun (Sam) Liu <yaxun.liu@amd.com>

Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"

This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and
40df06cdafc010002fc9cfe1dda73d689b7d27a6 with bu

Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"

This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and
40df06cdafc010002fc9cfe1dda73d689b7d27a6 with bug fixes for
memory sanitizer failure and Tensile build failure.

show more ...


# 0628bea5 19-Oct-2020 Hans Wennborg <hans@chromium.org>

Revert "[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting"

This broke Chromium's PGO build, it seems because hot-cold-splitting got turned
on unintentionally. See comment on the cod

Revert "[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting"

This broke Chromium's PGO build, it seems because hot-cold-splitting got turned
on unintentionally. See comment on the code review for repro etc.

> This patch adds -f[no-]split-cold-code CC1 options to clang. This allows
> the splitting pass to be toggled on/off. The current method of passing
> `-mllvm -hot-cold-split=true` to clang isn't ideal as it may not compose
> correctly (say, with `-O0` or `-Oz`).
>
> To implement the -fsplit-cold-code option, an attribute is applied to
> functions to indicate that they may be considered for splitting. This
> removes some complexity from the old/new PM pipeline builders, and
> behaves as expected when LTO is enabled.
>
> Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org>
> Differential Revision: https://reviews.llvm.org/D57265
> Reviewed By: Aditya Kumar, Vedant Kumar
> Reviewers: Teresa Johnson, Aditya Kumar, Fedor Sergeev, Philip Pfaffe, Vedant Kumar

This reverts commit 273c299d5d649a0222fbde03c9a41e41913751b4.

show more ...


# 273c299d 13-Oct-2020 Vedant Kumar <vsk@apple.com>

[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting

This patch adds -f[no-]split-cold-code CC1 options to clang. This allows
the splitting pass to be toggled on/off. The current metho

[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting

This patch adds -f[no-]split-cold-code CC1 options to clang. This allows
the splitting pass to be toggled on/off. The current method of passing
`-mllvm -hot-cold-split=true` to clang isn't ideal as it may not compose
correctly (say, with `-O0` or `-Oz`).

To implement the -fsplit-cold-code option, an attribute is applied to
functions to indicate that they may be considered for splitting. This
removes some complexity from the old/new PM pipeline builders, and
behaves as expected when LTO is enabled.

Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org>
Differential Revision: https://reviews.llvm.org/D57265
Reviewed By: Aditya Kumar, Vedant Kumar
Reviewers: Teresa Johnson, Aditya Kumar, Fedor Sergeev, Philip Pfaffe, Vedant Kumar

show more ...


# 79829a47 15-Oct-2020 Leonard Chan <leonardchan@google.com>

Revert "[clang] Add -fc++-abi= flag for specifying which C++ ABI to use"

This reverts commits 683b308c07bf827255fe1403056413f790e03729 and
8487bfd4e9ae186f9f588ef989d27a96cc2438c9.

We will go for a

Revert "[clang] Add -fc++-abi= flag for specifying which C++ ABI to use"

This reverts commits 683b308c07bf827255fe1403056413f790e03729 and
8487bfd4e9ae186f9f588ef989d27a96cc2438c9.

We will go for a more restricted approach that does not give freedom to
everyone to change ABIs on whichever platform.

See the discussion on https://reviews.llvm.org/D85802.

show more ...


# 683b308c 12-Aug-2020 Leonard Chan <leonardchan@google.com>

[clang] Add -fc++-abi= flag for specifying which C++ ABI to use

This implements the flag proposed in RFC http://lists.llvm.org/pipermail/cfe-dev/2020-August/066437.html.

The goal is to add a way to

[clang] Add -fc++-abi= flag for specifying which C++ ABI to use

This implements the flag proposed in RFC http://lists.llvm.org/pipermail/cfe-dev/2020-August/066437.html.

The goal is to add a way to override the default target C++ ABI through
a compiler flag. This makes it easier to test and transition between different
C++ ABIs through compile flags rather than build flags.

In this patch:
- Store `-fc++-abi=` in a LangOpt. This isn't stored in a
CodeGenOpt because there are instances outside of codegen where Clang
needs to know what the ABI is (particularly through
ASTContext::createCXXABI), and we should be able to override the
target default if the flag is provided at that point.
- Expose the existing ABIs in TargetCXXABI as values that can be passed
through this flag.
- Create a .def file for these ABIs to make it easier to check flag
values.
- Add an error for diagnosing bad ABI flag values.

Differential Revision: https://reviews.llvm.org/D85802

show more ...


# 77bb3ebe 13-Oct-2020 Artem Dergachev <artem.dergachev@gmail.com>

Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."

This reverts commit 44b7cf2983b6a8373c99a9b254f8c3f944e03f35.


# 44b7cf29 30-Jul-2020 Artem Dergachev <artem.dergachev@gmail.com>

[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.

With this change, we're more or less ready to allow users outside
of the Static Analyzer to take advantage of path diagn

[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.

With this change, we're more or less ready to allow users outside
of the Static Analyzer to take advantage of path diagnostic consumers
for emitting their warnings in different formats.

Differential Revision: https://reviews.llvm.org/D67422

show more ...


# 20898784 30-Sep-2020 Ties Stuij <ties.stuij@arm.com>

[ARM] Follow AACPS standard for volatile bit-fields access width

This patch resumes the work of D16586.
According to the AAPCS, volatile bit-fields should
be accessed using containers of the widht o

[ARM] Follow AACPS standard for volatile bit-fields access width

This patch resumes the work of D16586.
According to the AAPCS, volatile bit-fields should
be accessed using containers of the widht of their
declarative type. In such case:
```
struct S1 {
short a : 1;
}
```
should be accessed using load and stores of the width
(sizeof(short)), where now the compiler does only load
the minimum required width (char in this case).
However, as discussed in D16586,
that could overwrite non-volatile bit-fields, which
conflicted with C and C++ object models by creating
data race conditions that are not part of the bit-field,
e.g.
```
struct S2 {
short a;
int b : 16;
}
```
Accessing `S2.b` would also access `S2.a`.

The AAPCS Release 2020Q2
(https://documentation-service.arm.com/static/5efb7fbedbdee951c1ccf186?token=)
section 8.1 Data Types, page 36, "Volatile bit-fields -
preserving number and width of container accesses" has been
updated to avoid conflict with the C++ Memory Model.
Now it reads in the note:
```
This ABI does not place any restrictions on the access widths of bit-fields where the container
overlaps with a non-bit-field member or where the container overlaps with any zero length bit-field
placed between two other bit-fields. This is because the C/C++ memory model defines these as being
separate memory locations, which can be accessed by two threads simultaneously. For this reason,
compilers must be permitted to use a narrower memory access width (including splitting the access into
multiple instructions) to avoid writing to a different memory location. For example, in
struct S { int a:24; char b; }; a write to a must not also write to the location occupied by b, this requires at least two
memory accesses in all current Arm architectures. In the same way, in struct S { int a:24; int:0; int b:8; };,
writes to a or b must not overwrite each other.
```

I've updated the patch D16586 to follow such behavior by verifying that we
only change volatile bit-field access when:
- it won't overlap with any other non-bit-field member
- we only access memory inside the bounds of the record
- avoid overlapping zero-length bit-fields.

Regarding the number of memory accesses, that should be preserved, that will
be implemented by D67399.

Reviewed By: ostannard

Differential Revision: https://reviews.llvm.org/D72932

show more ...


# 71d3b7ec 09-Oct-2020 Anastasia Stulova <anastasia.stulova@arm.com>

[OpenCL] Add new compilation mode for OpenCL 3.0.

Extended -cl-std/std flag with CL3.0 and added predefined version macros.

Patch by Anton Zabaznov (azabaznov)!

Tags: #clang

Differential Revision

[OpenCL] Add new compilation mode for OpenCL 3.0.

Extended -cl-std/std flag with CL3.0 and added predefined version macros.

Patch by Anton Zabaznov (azabaznov)!

Tags: #clang

Differential Revision: https://reviews.llvm.org/D88300

show more ...


# 92bca128 08-Oct-2020 diggerlin <digger.llvm@gmail.com>

[AIX] add new option -mignore-xcoff-visibility

SUMMARY:

In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/kn

[AIX] add new option -mignore-xcoff-visibility

SUMMARY:

In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html.

We need to add the option -mignore-xcoff-visibility for compatibility with the IBM AIX OS (as the option is enabled by default in AIX). With this option llvm does not emit any visibility attribute to ASM or XCOFF object file.

The option only work on the AIX OS, for other non-AIX OS using the option will report an unsupported options error.

In AIX OS:

1.1 the option -mignore-xcoff-visibility is enabled by default , if there is not -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command .

1.2 if there is -fvisibility=* explicitly but not -mignore-xcoff-visibility explicitly in the clang command. it will generate visibility attributes.

1.3 if there are both -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command. The option "-mignore-xcoff-visibility" wins , it do not emit the visibility attribute.

The option -mignore-xcoff-visibility has no effect on visibility attribute when compile with -emit-llvm option to generated LLVM IR.

Reviewer: daltenty,Jason Liu

Differential Revision: https://reviews.llvm.org/D87451

show more ...


# 6668e4cc 07-Oct-2020 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload

Summary:
This patch adds an error to Clang that detects if OpenMP offloading is used
between two architectures with incom

[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload

Summary:
This patch adds an error to Clang that detects if OpenMP offloading is used
between two architectures with incompatible pointer sizes. This ensures that
the data mapping can be done correctly and solves an issue in code generation
generating the wrong size pointer.

Reviewer: jdoerfert

Subscribers: cfe-commits delcypher guansong llvm-commits sstefan1 yaxunl

Tags: #OpenMP #Clang

Differential Revision: https://reviews.llvm.org/D88594

show more ...


# 1dce692d 05-Oct-2020 Joseph Huber <jhuber6@vols.utk.edu>

Revert "[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload"

Reverting because detecting architecture size doesn't work on all
platforms.

This reverts commit eaf73293cb6b8d

Revert "[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload"

Reverting because detecting architecture size doesn't work on all
platforms.

This reverts commit eaf73293cb6b8d45dd85ffced57aea7ad4177754.

show more ...


# eaf73293 04-Oct-2020 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload

Summary:
This patch adds an error to Clang that detects if OpenMP offloading is
used between two architectures with incom

[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload

Summary:
This patch adds an error to Clang that detects if OpenMP offloading is
used between two architectures with incompatible pointer sizes. This
ensures that the data mapping can be done correctly and solves an issue
in code generation generating the wrong size pointer. This patch adds a
new lit substitution, %omp_powerpc_triple that, if the system is 32-bit or
64-bit, sets the powerpc triple accordingly. This was required to fix
some OpenMP tests that automatically populated the target architecture.

Reviewers: jdoerfert

Subscribers: cfe-commits guansong sstefan1 yaxunl delcypher

Tags: OpenMP clang LLVM

Differential Revision: https://reviews.llvm.org/D88594

show more ...


# bdc85292 30-Sep-2020 Joseph Huber <jhuber6@vols.utk.edu>

Revert "[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload"

Failing tests on Arm due to the tests automatically populating
incomatible pointer width architectures. Revertin

Revert "[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload"

Failing tests on Arm due to the tests automatically populating
incomatible pointer width architectures. Reverting until the tests are
updated. Failing tests:

OpenMP/distribute_parallel_for_num_threads_codegen.cpp
OpenMP/distribute_parallel_for_if_codegen.cpp
OpenMP/distribute_parallel_for_simd_if_codegen.cpp
OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp
OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp
OpenMP/teams_distribute_parallel_for_if_codegen.cpp
OpenMP/teams_distribute_parallel_for_simd_if_codegen.cpp

This reverts commit 9d2378b59150f6f1cb5c9cf42ea06b0bb57029a1.

show more ...


# 9d2378b5 30-Sep-2020 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload

Summary:
This patch adds an error to Clang that detects if OpenMP offloading is used
between two architectures with incom

[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload

Summary:
This patch adds an error to Clang that detects if OpenMP offloading is used
between two architectures with incompatible pointer sizes. This ensures that
the data mapping can be done correctly and solves an issue in code generation
generating the wrong size pointer.

Reviewer: jdoerfert

Subscribers:

Tags: #OpenMP #Clang

Differential Revision:

show more ...


# 3681be87 29-Sep-2020 Fangrui Song <i@maskray.me>

Add -fprofile-update={atomic,prefer-atomic,single}

GCC 7 introduced -fprofile-update={atomic,prefer-atomic} (prefer-atomic is for
best efforts (some targets do not support atomics)) to increment cou

Add -fprofile-update={atomic,prefer-atomic,single}

GCC 7 introduced -fprofile-update={atomic,prefer-atomic} (prefer-atomic is for
best efforts (some targets do not support atomics)) to increment counters
atomically, which is exactly what we have done with -fprofile-instr-generate
(D50867) and -fprofile-arcs (b5ef137c11b1cc6ae839ee75b49233825772bdd0).
This patch adds the option to clang to surface the internal options at driver level.

GCC 7 also turned on -fprofile-update=prefer-atomic when -pthread is specified,
but it has performance regression
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307). So we don't follow suit.

Differential Revision: https://reviews.llvm.org/D87737

show more ...


# 9263931f 25-Aug-2020 Alexey Bader <alexey.bader@intel.com>

[SYCL] Assume SYCL device functions are convergent

SYCL device compiler (similar to other SPMD compilers) assumes that
functions are convergent by default to avoid invalid transformations.
This attr

[SYCL] Assume SYCL device functions are convergent

SYCL device compiler (similar to other SPMD compilers) assumes that
functions are convergent by default to avoid invalid transformations.
This attribute can be removed if compiler can prove that function does
not have convergent operations.

Reviewed By: Naghasan

Differential Revision: https://reviews.llvm.org/D87282

show more ...


# 6f7fbdd2 18-Sep-2020 Ian Levesque <ianlevesque@fb.com>

[xray] Function coverage groups

Add the ability to selectively instrument a subset of functions by dividing the functions into N logical groups and then selecting a group to cover. By selecting diff

[xray] Function coverage groups

Add the ability to selectively instrument a subset of functions by dividing the functions into N logical groups and then selecting a group to cover. By selecting different groups over time you could cover the entire application incrementally with lower overhead than instrumenting the entire application at once.

Differential Revision: https://reviews.llvm.org/D87953

show more ...


# 3453b692 24-Sep-2020 Reid Kleckner <rnk@google.com>

Revert "Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions""

This reverts commit e39da8ab6a286ac777d5fe7799f1eb782cf99938.

This depends on a change that needs

Revert "Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions""

This reverts commit e39da8ab6a286ac777d5fe7799f1eb782cf99938.

This depends on a change that needs additional design review and needs
to be reverted.

show more ...


# e39da8ab 23-Sep-2020 Yaxun (Sam) Liu <yaxun.liu@amd.com>

Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"

This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and
40df06cdafc010002fc9cfe1dda73d689b7d27a6 after f

Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"

This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and
40df06cdafc010002fc9cfe1dda73d689b7d27a6 after fixing memory
sanitizer failure.

show more ...


# 772bd8a7 17-Sep-2020 Yaxun (Sam) Liu <yaxun.liu@amd.com>

Revert "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"

This reverts commit 7f1f89ec8d9944559042bb6d3b1132eabe3409de.

This reverts commit 40df06cdafc010002fc9cfe1dda

Revert "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"

This reverts commit 7f1f89ec8d9944559042bb6d3b1132eabe3409de.

This reverts commit 40df06cdafc010002fc9cfe1dda73d689b7d27a6.

show more ...


# 40df06cd 16-Sep-2020 Yaxun (Sam) Liu <yaxun.liu@amd.com>

[CUDA][HIP] Defer overloading resolution diagnostics for host device functions

In CUDA/HIP a function may become implicit host device function by
pragma or constexpr. A host device function is check

[CUDA][HIP] Defer overloading resolution diagnostics for host device functions

In CUDA/HIP a function may become implicit host device function by
pragma or constexpr. A host device function is checked in both
host and device compilation. However it may be emitted only
on host or device side, therefore the diagnostics should be
deferred until it is known to be emitted.

Currently clang is only able to defer certain diagnostics. This causes
false alarms and limits the usefulness of host device functions.

This patch lets clang defer all overloading resolution diagnostics for host device functions.

An option -fgpu-defer-diag is added to control this behavior. By default
it is off.

It is NFC for other languages.

Differential Revision: https://reviews.llvm.org/D84364

show more ...


# f1a3ab90 02-Sep-2020 Snehasish Kumar <snehasishk@google.com>

[clang] Add a command line flag for the Machine Function Splitter.

This patch adds a command line flag for the machine function splitter
(added in rG94faadaca4e1).

-fsplit-machine-functions
Split m

[clang] Add a command line flag for the Machine Function Splitter.

This patch adds a command line flag for the machine function splitter
(added in rG94faadaca4e1).

-fsplit-machine-functions
Split machine functions using profile information (x86 ELF). On
other targets an error is emitted. If profile information is not
provided a warning is emitted notifying the user that profile
information is required.

Differential Revision: https://reviews.llvm.org/D87047

show more ...


# 226d80eb 14-Sep-2020 Teresa Johnson <tejohnson@google.com>

[MemProf] Rename HeapProfiler to MemProfiler for consistency

This is consistent with the clang option added in
7ed8124d46f94601d5f1364becee9cee8538265e, and the comments on the
runtime patch in D871

[MemProf] Rename HeapProfiler to MemProfiler for consistency

This is consistent with the clang option added in
7ed8124d46f94601d5f1364becee9cee8538265e, and the comments on the
runtime patch in D87120.

Differential Revision: https://reviews.llvm.org/D87622

show more ...


# a874d633 12-Sep-2020 Florian Hahn <flo@fhahn.com>

[Clang] Add option to allow marking pass-by-value args as noalias.

After the recent discussion on cfe-dev 'Can indirect class parameters be
noalias?' [1], it seems like using using noalias is proble

[Clang] Add option to allow marking pass-by-value args as noalias.

After the recent discussion on cfe-dev 'Can indirect class parameters be
noalias?' [1], it seems like using using noalias is problematic for
current C++, but should be allowed for C-only code.

This patch introduces a new option to let the user indicate that it is
safe to mark indirect class parameters as noalias. Note that this also
applies to external callers, e.g. it might not be safe to use this flag
for C functions that are called by C++ functions.

In targets that allocate indirect arguments in the called function, this
enables more agressive optimizations with respect to memory operations
and brings a ~1% - 2% codesize reduction for some programs.

[1] : http://lists.llvm.org/pipermail/cfe-dev/2020-July/066353.html

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D85473

show more ...


1...<<11121314151617181920>>...79