[tbaa] Handle base classes in struct tbaa

This is a fix for the miscompilation reported in https://github.com/llvm/llvm-project/issues/55384

Not adding a new test case since existing test cases alr

[tbaa] Handle base classes in struct tbaa

This is a fix for the miscompilation reported in https://github.com/llvm/llvm-project/issues/55384

Not adding a new test case since existing test cases already cover base classes (including new-struct-path tbaa).

Reviewed By: jeroen.dobbelaere

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

show more ...

Revert "[tbaa] Handle base classes in struct tbaa"

This reverts commit cdc59e2202c11a6a5dfd2ec83531523c58eaae45.

The Verifier finds a problem in a stage2 build. Reverting so Bruno can investigate.

[tbaa] Handle base classes in struct tbaa

This is a fix for the miscompilation reported in https://github.com/llvm/llvm-project/issues/55384

Not adding a new test case since existing test cases alr

[tbaa] Handle base classes in struct tbaa

This is a fix for the miscompilation reported in https://github.com/llvm/llvm-project/issues/55384

Not adding a new test case since existing test cases already cover base classes (including new-struct-path tbaa).

Reviewed By: jeroen.dobbelaere

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

show more ...

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be p

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

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

show more ...

[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences

For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie
and COFF, but not for Mach-O.

[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences

For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie
and COFF, but not for Mach-O. This nuance causes unneeded binary format differences.

This patch replaces (function) `define ` with `define{{.*}} `,
(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `
if there is an explicit linkage.

* Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar.
* Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.

show more ...

Update existed CodeGen TBAA tests

Reviewers: hfinkel, kosarev, rjmccall

Reviewed By: rjmccall

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

llvm-svn: 331292

Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.

Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Cla

Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.

Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.

There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.

This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.

This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.

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

llvm-svn: 290392

show more ...

[PR26550] Use a different TBAA root for C++ vs C.

This commit changes the root from "Simple C/C++ TBAA" to "Simple C++ TBAA" for
C++.

The problem is that the type name in the TBAA nodes is generate

[PR26550] Use a different TBAA root for C++ vs C.

This commit changes the root from "Simple C/C++ TBAA" to "Simple C++ TBAA" for
C++.

The problem is that the type name in the TBAA nodes is generated differently
for C vs C++. If we link an IR file for C with an IR file for C++, since they
have the same root and the type names are different, accesses to the two type
nodes will be considered no-alias, even though the two type nodes are from
the same type in a header file.

The fix is to use different roots for C and C++. Types from C will be treated
conservatively in respect to types from C++.

Follow-up commits will change the C root to "Simple C TBAA" plus some mangling
change for C types to make it a little more aggresive.

llvm-svn: 260567

show more ...

Compute and preserve alignment more faithfully in IR-generation.

Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. C

Compute and preserve alignment more faithfully in IR-generation.

Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.

As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.

The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.

Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.

We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.

Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.

ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.

I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.

llvm-svn: 246985

show more ...

IR: Make metadata typeless in assembly, clang side

Match LLVM changes from r224257.

llvm-svn: 224259

Turn struct-path aware TBAA on by default.

Use -no-struct-path-tbaa to turn it off.
This is the same as r191695, which was reverted because it depends on a
commit that has issues.

llvm-svn: 192497

TBAA: use the same format for scalar TBAA and struct-path aware TBAA.

An updated version of r191586 with bug fix.

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA

TBAA: use the same format for scalar TBAA and struct-path aware TBAA.

An updated version of r191586 with bug fix.

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.

We should not generate a TBAA tag with null being the first field. When
a TBAA type node is null, the tag should be null too. Make sure we
don't decorate an instruction with a null TBAA tag.

Added a testing case for the bug reported by Richard with -relaxed-aliasing
and -fsanitizer=thread.

llvm-svn: 192145

show more ...

Revert r191586 and r191695. They cause crashes when building with
-relaxed-aliasing.

llvm-svn: 191725

Turn struct-path aware TBAA on by default.

Use -no-struct-path-tbaa to turn it off.

llvm-svn: 191695

TBAA: use the same format for scalar TBAA and struct-path aware TBAA.

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.

llvm-s

TBAA: use the same format for scalar TBAA and struct-path aware TBAA.

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.

llvm-svn: 191586

show more ...

Make these tests more robust against IRgen choosing to emit more named metadata.

llvm-svn: 186279

Struct-path aware TBAA: enable struct-path aware TBAA for classes.

llvm-svn: 180795