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

[Clang,TBAA] Use pattern for metadata reference in test.

Update the single check line that still had a hard-coded metadata
reference. This makes it more robust to slight changes in the metadata
numb

[Clang,TBAA] Use pattern for metadata reference in test.

Update the single check line that still had a hard-coded metadata
reference. This makes it more robust to slight changes in the metadata
numbering.

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

Fix TBAA representation for zero-sized fields and unnamed bit-fields.

Unnamed bit-fields should not be represented in the TBAA metadata
because they do not represent storage fields (they only affect

Fix TBAA representation for zero-sized fields and unnamed bit-fields.

Unnamed bit-fields should not be represented in the TBAA metadata
because they do not represent storage fields (they only affect layout).

Zero-sized fields should not be represented in the TBAA metadata
because by definition they have no associated storage (so we will never
emit a load or store through them), and they might not appear in
declaration order within the struct layout.

Fixes a verifier failure when emitting a TBAA-enabled load through a
class type containing a zero-sized field.

llvm-svn: 364140

show more ...

[CodeGen] Support generation of TBAA info in the new format

Now that the MDBuilder helpers generating TBAA type and access
descriptors in the new format are in place, we can teach clang to
use them

[CodeGen] Support generation of TBAA info in the new format

Now that the MDBuilder helpers generating TBAA type and access
descriptors in the new format are in place, we can teach clang to
use them when requested.

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

llvm-svn: 321351

show more ...

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

Add negative test for TBAA

Revision r178818 added tests for TBAA but was missing negative tests to ensure
that TBAA markers are not emitted when TBAA is off.

Differential Revision: http://reviews.l

Add negative test for TBAA

Revision r178818 added tests for TBAA but was missing negative tests to ensure
that TBAA markers are not emitted when TBAA is off.

Differential Revision: http://reviews.llvm.org/D21295

llvm-svn: 274610

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

Update Clang tests to handle explicitly typed load changes in LLVM.

llvm-svn: 230795

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

TBAA: add testing case to check typedef can alias.

llvm-svn: 188931

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

llvm-svn: 186279

Rewrite record layout for ms_struct structs.

The old implementation of ms_struct in RecordLayoutBuilder was a
complete mess: it depended on complicated conditionals which didn't
really reflect the u

Rewrite record layout for ms_struct structs.

The old implementation of ms_struct in RecordLayoutBuilder was a
complete mess: it depended on complicated conditionals which didn't
really reflect the underlying logic, and placed a burden on users of
the resulting RecordLayout. This commit rips out almost all of the
old code, and replaces it with simple checks in
RecordLayoutBuilder::LayoutBitField.

This commit also fixes <rdar://problem/14252115>, a bug where class
inheritance would cause us to lay out bitfields incorrectly.

llvm-svn: 185018

show more ...

Struct-path aware TBAA: change the format of TBAAStructType node.

We switch the order of offset and field type to make TBAAStructType node
(name, parent node, offset) similar to scalar TBAA node (na

Struct-path aware TBAA: change the format of TBAAStructType node.

We switch the order of offset and field type to make TBAAStructType node
(name, parent node, offset) similar to scalar TBAA node (name, parent node).

llvm-svn: 180653

show more ...

TBAA: make sure zero-length bitfield works for tbaa.struct and path-aware tbaa

For ms structs, zero-length bitfields following non-bitfield members are
completely ignored, we should not increase the

TBAA: make sure zero-length bitfield works for tbaa.struct and path-aware tbaa

For ms structs, zero-length bitfields following non-bitfield members are
completely ignored, we should not increase the field index.
Before the fix, we will have an assertion failure.

llvm-svn: 180038

show more ...

Struct-path aware TBAA: uniformize scalar tag and path tag.

For struct-path aware TBAA, we used to use scalar type node as the scalar tag,
which has an incompatible format with the struct path tag.

Struct-path aware TBAA: uniformize scalar tag and path tag.

For struct-path aware TBAA, we used to use scalar type node as the scalar tag,
which has an incompatible format with the struct path tag. We now use the same
format: base type, access type and offset.

We also uniformize the scalar type node and the struct type node: name, a list
of pairs (offset + pointer to MDNode). For scalar type, we have a single pair.
These are to make implementaiton of aliasing rules easier.

llvm-svn: 179335

show more ...

Try to appease the atom buildbots

llvm-svn: 178898

Add triple to testing case to appease poewrpc64 buildbots

llvm-svn: 178886

Add testing case for r178797

llvm-svn: 178818