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

This reverts commit 514df1b2bb1ecd1a33327001ea38a347fd2d0380.

Some of the buildbots got llvm-lit errors on CodeGen/volatile

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

This reverts commit 514df1b2bb1ecd1a33327001ea38a347fd2d0380.

Some of the buildbots got llvm-lit errors on CodeGen/volatile.c

show more ...

[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.
```

Patch D16586 was updated 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.

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

The following people contributed to this patch:
- Diogo Sampaio
- Ties Stuij

show more ...

[HeapProf] Address post-review comments in instrumentation code

Addresses post-review comments from D85948, which can be found here:
https://reviews.llvm.org/rG7ed8124d46f9.

Make -fvisibility-inlines-hidden apply to static local variables in inline functions on Darwin

This effectively disables r340386 on Darwin, and provides a command line flag
to opt into/out of this b

Make -fvisibility-inlines-hidden apply to static local variables in inline functions on Darwin

This effectively disables r340386 on Darwin, and provides a command line flag
to opt into/out of this behaviour. This change is needed to compile certain
Apple headers correctly.

rdar://47688592

Differential revision: https://reviews.llvm.org/D86881

show more ...

[HeapProf] Clang and LLVM support for heap profiling instrumentation

See RFC for background:
http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html

Note that the runtime changes will be sen

[HeapProf] Clang and LLVM support for heap profiling instrumentation

See RFC for background:
http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html

Note that the runtime changes will be sent separately (hopefully this
week, need to add some tests).

This patch includes the LLVM pass to instrument memory accesses with
either inline sequences to increment the access count in the shadow
location, or alternatively to call into the runtime. It also changes
calls to memset/memcpy/memmove to the equivalent runtime version.
The pass is modeled on the address sanitizer pass.

The clang changes add the driver option to invoke the new pass, and to
link with the upcoming heap profiling runtime libraries.

Currently there is no attempt to optimize the instrumentation, e.g. to
aggregate updates to the same memory allocation. That will be
implemented as follow on work.

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

show more ...

[X86] Default to -mtune=generic unless -march is passed to the driver. Add TuneCPU to the AST serialization

This patch defaults to -mtune=generic unless -march is present. If -march is present we'll

[X86] Default to -mtune=generic unless -march is passed to the driver. Add TuneCPU to the AST serialization

This patch defaults to -mtune=generic unless -march is present. If -march is present we'll use the empty string unless its overridden by mtune. The back should use the target cpu if the tune-cpu isn't present.

It also adds AST serialization support to fix some tests that emit AST and parse it back. These tests diff the IR against the output from not going through AST. So if we don't serialize the tune CPU we fail the diff.

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

show more ...

[LiveDebugValues] Add switches for using instr-ref variable locations

This patch adds the -Xclang option
"-fexperimental-debug-variable-locations" and same LLVM CodeGen option,
to pick which variabl

[LiveDebugValues] Add switches for using instr-ref variable locations

This patch adds the -Xclang option
"-fexperimental-debug-variable-locations" and same LLVM CodeGen option,
to pick which variable location tracking solution to use.

Right now all the switch does is pick which LiveDebugValues
implementation to use, the normal VarLoc one or the instruction
referencing one in rGae6f78824031. Over time, the aim is to add fragments
of support in aid of the value-tracking RFC:

http://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html

also controlled by this command line switch. That will slowly move
variable locations to be defined by an instruction calculating a value,
and a DBG_INSTR_REF instruction referring to that value. Thus, this is
going to grow into a "use the new kind of variable locations" switch,
rather than just "use the new LiveDebugValues implementation".

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

show more ...

[AST][RecoveryAST] Preserve the type by default for recovery expression.

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

[X86] Add basic support for -mtune command line option in clang

Building on the backend support from D85165. This parses the command line option in the driver, passes it on to CC1 and adds a functio

[X86] Add basic support for -mtune command line option in clang

Building on the backend support from D85165. This parses the command line option in the driver, passes it on to CC1 and adds a function attribute.

-Still need to support tune on the target attribute.
-Need to use "generic" as the tuning by default. But need to change generic in the backend first.
-Need to set tune if march is specified and mtune isn't.
-May need to disable getHostCPUName's ability to guess CPU name from features when it doesn't have a family/model match for mtune=native. That's what gcc appears to do.

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

show more ...

[clang] fix a compilation bug

With gcc 6.3.0, I hit the following compilation bug:
/home/yhs/work/llvm-project/clang/lib/Frontend/CompilerInvocation.cpp:
In function ‘bool ParseCodeGenArgs(clang

[clang] fix a compilation bug

With gcc 6.3.0, I hit the following compilation bug:
/home/yhs/work/llvm-project/clang/lib/Frontend/CompilerInvocation.cpp:
In function ‘bool ParseCodeGenArgs(clang::CodeGenOptions&, llvm::opt::ArgList&,
clang::InputKind, clang::DiagnosticsEngine&, const clang::TargetOptions&,
const clang::FrontendOptions&)’:
/home/yhs/work/llvm-project/clang/lib/Frontend/CompilerInvocation.cpp:780:12:
error: unused variable ‘A’ [-Werror=unused-variable]
if (Arg *A = Args.getLastArg(OPT_fuse_ctor_homing))
^
cc1plus: all warnings being treated as errors

The bug is introduced by Commit ae6523cd62a4 ("[DebugInfo] Add
-fuse-ctor-homing cc1 flag so we can turn on constructor homing only
if limited debug info is already on.")

show more ...

[DebugInfo] Add -fuse-ctor-homing cc1 flag so we can turn on constructor homing only if limited debug info is already on.

This adds a cc1 flag to enable constructor homing but doesn't turn on debug

[DebugInfo] Add -fuse-ctor-homing cc1 flag so we can turn on constructor homing only if limited debug info is already on.

This adds a cc1 flag to enable constructor homing but doesn't turn on debug
info if it wasn't enabled already (which is what using
-debug-info-kind=constructor does). This will be used for testing, and won't
be needed anymore once ctor homing is used as default / merged into =limited.

Bug to enable ctor homing: https://bugs.llvm.org/show_bug.cgi?id=46537

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

show more ...

[SystemZ][z/OS] enable trigraphs by default on z/OS

This patch enables trigraphs on z/OS.

Reviewed By: hubert.reinterpretcast, fanbo-meng

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

[Clang] implement -fno-eliminate-unused-debug-types

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Resubmit after breaking Windows and OSX builds.

Reviewed By: dblaikie

[Clang] implement -fno-eliminate-unused-debug-types

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Resubmit after breaking Windows and OSX builds.

Reviewed By: dblaikie

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

show more ...

Revert "[Clang] implement -fno-eliminate-unused-debug-types"

This reverts commit e486921fd6cf96ae9114adac455f7c0b5c1088a7.

Breaks windows builds and osx builds.

[Clang] implement -fno-eliminate-unused-debug-types

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Reviewed By: dblaikie

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

[Clang] implement -fno-eliminate-unused-debug-types

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Reviewed By: dblaikie

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

show more ...

Reland D61689 Change -gz and -Wa,--compress-debug-sections to use gABI compression (SHF_COMPRESSED) with integrated assembler

This fixes an inconsistency: clang -c -gz -fno-integrated-as means SHF_C

Reland D61689 Change -gz and -Wa,--compress-debug-sections to use gABI compression (SHF_COMPRESSED) with integrated assembler

This fixes an inconsistency: clang -c -gz -fno-integrated-as means SHF_COMPRESSED
while clang -c -gz -fintegrated-as means zlib-gnu.

---

Since July 15, 2015 (binutils-gdb commit
19a7fe52ae3d0971e67a134bcb1648899e21ae1c, included in 2.26), gas
--compress-debug-sections=zlib (gcc -gz) means zlib-gabi:
SHF_COMPRESSED. Before that GCC/binutils used zlib-gnu (.zdebug).

clang's -gz was introduced in rC306115 (Jun 2017) to indicate zlib-gnu. It
is 2020 now and it is not unreasonable to assume users of the new
feature to have new linkers (ld.bfd/gold >= 2.26, lld >= rLLD273661).

Change clang's default accordingly to improve standard conformance.
zlib-gnu becomes out of fashion and gets poorer toolchain support.
Its mangled names confuse tools and are more likely to cause problems.

Reviewed By: compnerd

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

show more ...

accept 'clang++ -c a.pch -o a.o' to create PCH's object file

This way should be the same like with a.pcm for modules.
An alternative way is 'clang++ -c empty.cpp -include-pch a.pch -o a.o
-Xclang -b

accept 'clang++ -c a.pch -o a.o' to create PCH's object file

This way should be the same like with a.pcm for modules.
An alternative way is 'clang++ -c empty.cpp -include-pch a.pch -o a.o
-Xclang -building-pch-with-obj', which is what clang-cl's /Yc does
internally.

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

show more ...

[Sema][AArch64] Add parsing support for arm_sve_vector_bits attribute

Summary:

This patch implements parsing support for the 'arm_sve_vector_bits' type
attribute, defined by the Arm C Language Exte

[Sema][AArch64] Add parsing support for arm_sve_vector_bits attribute

Summary:

This patch implements parsing support for the 'arm_sve_vector_bits' type
attribute, defined by the Arm C Language Extensions (ACLE, version 00bet5,
section 3.7.3) for SVE [1].

The purpose of this attribute is to define fixed-length (VLST) versions
of existing sizeless types (VLAT). For example:

#if __ARM_FEATURE_SVE_BITS==512
typedef svint32_t fixed_svint32_t __attribute__((arm_sve_vector_bits(512)));
#endif

Creates a type 'fixed_svint32_t' that is a fixed-length version of
'svint32_t' that is normal-sized (rather than sizeless) and contains
exactly 512 bits. Unlike 'svint32_t', this type can be used in places
such as structs and arrays where sizeless types can't.

Implemented in this patch is the following:

* Defined and tested attribute taking single argument.
* Checks the argument is an integer constant expression.
* Attribute can only be attached to a single SVE vector or predicate
type, excluding tuple types such as svint32x4_t.
* Added the `-msve-vector-bits=<bits>` flag. When specified the
`__ARM_FEATURE_SVE_BITS__EXPERIMENTAL` macro is defined.
* Added a language option to store the vector size specified by the
`-msve-vector-bits=<bits>` flag. This is used to validate `N ==
__ARM_FEATURE_SVE_BITS`, where N is the number of bits passed to the
attribute and `__ARM_FEATURE_SVE_BITS` is the feature macro defined under
the same flag.

The `__ARM_FEATURE_SVE_BITS` macro will be made non-experimental in the final
patch of the series.

[1] https://developer.arm.com/documentation/100987/latest

This is patch 1/4 of a patch series.

Reviewers: sdesmalen, rsandifo-arm, efriedma, ctetreau, cameron.mcinally, rengolin, aaron.ballman

Reviewed By: sdesmalen, aaron.ballman

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

show more ...

[clang] Teach -fembed-bitcode option not to embed W_value Group

Summary:
-fembed-bitcode options doesn't embed warning options since they are
useless to code generation. Make sure it handles the W_v

[clang] Teach -fembed-bitcode option not to embed W_value Group

Summary:
-fembed-bitcode options doesn't embed warning options since they are
useless to code generation. Make sure it handles the W_value group and
not embed those options in the output.

Reviewers: zixuw, arphaman

Reviewed By: zixuw

Subscribers: jkorous, dexonsmith, ributzka, cfe-commits

Tags: #clang

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

show more ...

[LPM] Port CGProfilePass from NPM to LPM

Reviewers: hans, chandlerc!, asbirlea, nikic

Reviewed By: hans, nikic

Subscribers: steven_wu, dexonsmith, nikic, echristo, void, zhizhouy, cfe-commits, aeu

[LPM] Port CGProfilePass from NPM to LPM

Reviewers: hans, chandlerc!, asbirlea, nikic

Reviewed By: hans, nikic

Subscribers: steven_wu, dexonsmith, nikic, echristo, void, zhizhouy, cfe-commits, aeubanks, MaskRay, jvesely, nhaehnle, hiraditya, kerbowa, llvm-commits

Tags: #llvm, #clang

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

show more ...

Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support."

We currently have strict floating point/constrained floating point enabled
for all targets. Constrained

Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support."

We currently have strict floating point/constrained floating point enabled
for all targets. Constrained SDAG nodes get converted to the regular ones
before reaching the target layer. In theory this should be fine.

However, the changes are exposed to users through multiple clang options
already in use in the field, and the changes are _completely_ _untested_
on almost all of our targets. Bugs have already been found, like
"https://bugs.llvm.org/show_bug.cgi?id=45274".

This patch disables constrained floating point options in clang everywhere
except X86 and SystemZ. A warning will be printed when this happens.

Use the new -fexperimental-strict-floating-point flag to force allowing
strict floating point on hosts that aren't already marked as supporting
it (X86 and SystemZ).

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

show more ...

Add diagnostic option backing field for -fansi-escape-codes

Summary:
Keep track of -fansi-escape-codes in DiagnosticOptions and move the
option to the new option parsing system.

Depends on D82860

Add diagnostic option backing field for -fansi-escape-codes

Summary:
Keep track of -fansi-escape-codes in DiagnosticOptions and move the
option to the new option parsing system.

Depends on D82860

Reviewers: Bigcheese

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

show more ...

Revert D83013 "[LPM] Port CGProfilePass from NPM to LPM"

This reverts commit c92a8c0a0f68fbbb23e3fdde071007e63a552e82.

It breaks builds and has unaddressed review comments.

[LPM] Port CGProfilePass from NPM to LPM

Reviewers: hans, chandlerc!, asbirlea, nikic

Reviewed By: hans, nikic

Subscribers: steven_wu, dexonsmith, nikic, echristo, void, zhizhouy, cfe-commits, aeu

[LPM] Port CGProfilePass from NPM to LPM

Reviewers: hans, chandlerc!, asbirlea, nikic

Reviewed By: hans, nikic

Subscribers: steven_wu, dexonsmith, nikic, echristo, void, zhizhouy, cfe-commits, aeubanks, MaskRay, jvesely, nhaehnle, hiraditya, kerbowa, llvm-commits

Tags: #llvm, #clang

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

show more ...

[clang] Include missing LangOpts in `getModuleHash`.

`ObjCRuntime` and `CommentOpts.BlockCommandNames` are checked by
`ASTReader::checkLanguageOptions`, but are not part of the module
context hash.

[clang] Include missing LangOpts in `getModuleHash`.

`ObjCRuntime` and `CommentOpts.BlockCommandNames` are checked by
`ASTReader::checkLanguageOptions`, but are not part of the module
context hash. This can lead to errors when using implicit modules if
different TUs have different values for these options when using the
same module cache.

This was not hit very often due to the rare usage of
`-fblock-command-names=` and that `ObjCRuntime` is by default set by
the target triple, which is part of the existing context hash.

show more ...