[ConstantFolding] Infer getelementptr nuw flag (#119214)

Infer nuw from nusw and nneg. This is the constant expression variant of
https://github.com/llvm/llvm-project/pull/111144.

Proof: https:/

[ConstantFolding] Infer getelementptr nuw flag (#119214)

Infer nuw from nusw and nneg. This is the constant expression variant of
https://github.com/llvm/llvm-project/pull/111144.

Proof: https://alive2.llvm.org/ce/z/ihztLy

show more ...

[InstCombine] Infer nusw + nneg -> nuw for getelementptr (#111144)

If the gep is nusw (usually via inbounds) and the offset is
non-negative, we can infer nuw.

Proof: https://alive2.llvm.org/ce/z

[InstCombine] Infer nusw + nneg -> nuw for getelementptr (#111144)

If the gep is nusw (usually via inbounds) and the offset is
non-negative, we can infer nuw.

Proof: https://alive2.llvm.org/ce/z/ihztLy

show more ...

[LLVM][IR] Use splat syntax when printing Constant[Data]Vector. (#112548)

[IRBuilder] Generate nuw GEPs for struct member accesses (#99538)

Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update

[IRBuilder] Generate nuw GEPs for struct member accesses (#99538)

Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update scripts where possible, and by
find + replace where not.

show more ...

[clang] Skip auto-init on scalar vars that have a non-constant Init and no self-ref (#94642)

In that scalar case, the Init should initialize the auto var before use. The Init might use uninitialized

[clang] Skip auto-init on scalar vars that have a non-constant Init and no self-ref (#94642)

In that scalar case, the Init should initialize the auto var before use. The Init might use uninitialized memory from other sources (e.g., heap) but auto-init did not help us in that case because the auto-init would have been overwritten by the Init before use.

For non-scalars e.g., classes, the Init expr might be a ctor call that leaves uninitialized members, so we leave the auto-init there.

The motivation is to have less IR for the optimizer to later remove, which may not be until a fairly late pass (DSE) or may not get optimized in lower optimization levels like O1 (no DSE) or sometimes due to derefinement.
This is ~10% less left-over auto-init in O1 in a few examples checked.

show more ...

[ConstantFolding] Canonicalize constexpr GEPs to i8 (#89872)

This patch canonicalizes constant expression GEPs to use i8 source
element type, aka ptradd. This is the ConstantFolding equivalent of t

[ConstantFolding] Canonicalize constexpr GEPs to i8 (#89872)

This patch canonicalizes constant expression GEPs to use i8 source
element type, aka ptradd. This is the ConstantFolding equivalent of the
InstCombine canonicalization introduced in #68882.

I believe all our optimizations working on constant expression GEPs
(like GlobalOpt etc) have already been switched to work on offsets, so I
don't expect any significant fallout from this change.

This is part of:
https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699

show more ...

[clang][CodeGen] Allow `memcpy` replace with trivial auto var init

When emitting the storage (or memory copy operations) for constant
initializers, the decision whether to split a constant structure

[clang][CodeGen] Allow `memcpy` replace with trivial auto var init

When emitting the storage (or memory copy operations) for constant
initializers, the decision whether to split a constant structure or
array store into a sequence of field stores or to use `memcpy` is
based upon the optimization level and the size of the initializer.
In afe8b93ffdfef5d8879e1894b9d7dda40dee2b8d, we extended this by
allowing constants to be split when the array (or struct) type does
not match the type of data the address to the object (constant) is
expected to contain. This may happen when `emitStoresForConstant` is
called by `EmitAutoVarInit`, as the element type of the address gets
shrunk. When this occurs, let the initializer be split into a bunch
of stores only under `-ftrivial-auto-var-init=pattern`.

Fixes: https://github.com/llvm/llvm-project/issues/84178.

show more ...

[IR] Change representation of getelementptr inrange (#84341)

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the

[IR] Change representation of getelementptr inrange (#84341)

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the representation of the `inrange` attribute, which
is used for vtable splitting.

Currently, inrange is specified as follows:

```
getelementptr inbounds ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, inrange i32 1, i64 2)
```

The `inrange` is placed on a GEP index, and all accesses must be "in
range" of that index. The new representation is as follows:

```
getelementptr inbounds inrange(-16, 16) ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, i32 1, i64 2)
```

This specifies which offsets are "in range" of the GEP result. The new
representation will continue working when canonicalizing to ptradd
representation:

```
getelementptr inbounds inrange(-16, 16) (i8, ptr @vt, i64 48)
```

The inrange offsets are relative to the return value of the GEP. An
alternative design could make them relative to the source pointer
instead. The result-relative format was chosen on the off-chance that we
want to extend support to non-constant GEPs in the future, in which case
this variant is more expressive.

This implementation "upgrades" the old inrange representation in bitcode
by simply dropping it. This is a very niche feature, and I don't think
trying to upgrade it is worthwhile. Let me know if you disagree.

show more ...

[clang] Avoid memcopy for small structure with padding under -ftrivial-auto-var-init (#71677)

Recommit of 0d2860b795879f4dd152963b52f969b53b136899 with extra test
cases fixed.

Revert "[clang] Avoid memcopy for small structure with padding under -ftrivial-auto-var-init (#71677)"

This reverts commit fe5c360a9aae61db37886c0c795c409b5129905f.
The commit causes the tests below

Revert "[clang] Avoid memcopy for small structure with padding under -ftrivial-auto-var-init (#71677)"

This reverts commit fe5c360a9aae61db37886c0c795c409b5129905f.
The commit causes the tests below to fail on many buildbots, e.g.
https://lab.llvm.org/buildbot/#/builders/245/builds/17047

Clang :: CodeGen/aapcs-align.cpp
Clang :: CodeGen/aapcs64-align.cpp

show more ...

[clang] Avoid memcopy for small structure with padding under -ftrivial-auto-var-init (#71677)

Recommit of 0d2860b795879f4dd152963b52f969b53b136899 with extra test
cases fixed.

Revert "[clang] Avoid memcopy for small structure with padding under -ftrivial-auto-var-init (#71677)"

This reverts commit 0d2860b795879f4dd152963b52f969b53b136899.

This change appears to have brok

Revert "[clang] Avoid memcopy for small structure with padding under -ftrivial-auto-var-init (#71677)"

This reverts commit 0d2860b795879f4dd152963b52f969b53b136899.

This change appears to have broken several clang tests on following buildbots:
https://lab.llvm.org/buildbot/#/builders/245
https://lab.llvm.org/buildbot/#/builders/188
https://lab.llvm.org/buildbot/#/builders/186
https://lab.llvm.org/buildbot/#/builders/183

show more ...

[clang] Avoid memcopy for small structure with padding under -ftrivial-auto-var-init (#71677)

[CodeGenCXX] Convert some tests to opaque pointers (NFC)

In particular also fixes fallout from instcombine changes.

[test] Remove various legacy pass manager tests

The new PM been the default for a while and we're in the process of removing the legacy PM optimization pipeline.

[test] Remove references to -fexperimental-new-pass-manager in tests

This has been the default for a while and we're in the process of removing the legacy PM optimization pipeline.

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

Reland "[Libcalls, Attrs] Annotate libcalls with noundef"

Fixed Clang tests.

[InstCombine] Preserve !annotation on newly created instructions.

If the source instruction has !annotation metadata, all instructions
created during combining should also have it. Tell the builder

[InstCombine] Preserve !annotation on newly created instructions.

If the source instruction has !annotation metadata, all instructions
created during combining should also have it. Tell the builder to
add it.

The !annotation system was discussed on llvm-dev as part of
'RFC: Combining Annotation Metadata and Remarks'
(http://lists.llvm.org/pipermail/llvm-dev/2020-November/146393.html)

This patch is based on an earlier patch by Francis Visoiu Mistrih.

Reviewed By: thegameg, lebedev.ri

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

show more ...

[IRGen] Add !annotation metadata for auto-init stores.

This patch updates Clang's IRGen to add !annotation nodes with an
"auto-init" annotation to all stores for auto-initialization.

As discussed i

[IRGen] Add !annotation metadata for auto-init stores.

This patch updates Clang's IRGen to add !annotation nodes with an
"auto-init" annotation to all stores for auto-initialization.

As discussed in 'RFC: Combining Annotation Metadata and Remarks'
(http://lists.llvm.org/pipermail/llvm-dev/2020-November/146393.html)
this allows using optimization remarks to track down where auto-init
code was inserted (and not removed by optimizations).

There are a few cases in the tests where !annotation gets dropped by
optimizations. Those optimizations will be updated in subsequent
patches.

This patch is based on a patch by Francis Visoiu Mistrih.

Reviewed By: thegameg, paquette

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

show more ...

[clang] Add missing FileCheck colons

[clang codegen] Clean up handling of vectors with trivial-auto-var-init.

The code was pretending to be doing something useful with vectors, but
really it was doing nothing: the element type of a vec

[clang codegen] Clean up handling of vectors with trivial-auto-var-init.

The code was pretending to be doing something useful with vectors, but
really it was doing nothing: the element type of a vector is always a
scalar type, so constWithPadding would always just return the input constant.

Split off from D75661 so it can be reviewed separately.

While I'm here, also add testcase to show missing vector handling.

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

show more ...

Revert "Revert "As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there.""

This reapplies: 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4

Original commit message:

As

Revert "Revert "As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there.""

This reapplies: 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4

Original commit message:

As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there.

This change doesn't include any change to move from selection dag to fast isel
and that will come with other numbers that should help inform that decision.
There also haven't been any real debuggability studies with this pipeline yet,
this is just the initial start done so that people could see it and we could start
tweaking after.

Test updates: Outside of the newpm tests most of the updates are coming from either
optimization passes not run anymore (and without a compelling argument at the moment)
that were largely used for canonicalization in clang.

Original post:

http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html

Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65410

This reverts commit c9ddb02659e3ece7a0d9d6b4dac7ceea4ae46e6d.

show more ...

Revert "As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there."

This reverts commit 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4.

This commit introduced 9 new fail

Revert "As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there."

This reverts commit 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4.

This commit introduced 9 new failures on lldb buildbot host at http://lab.llvm.org:8014/builders/lldb-aarch64-ubuntu

Following tests were failing:
lldb-api :: functionalities/tail_call_frames/ambiguous_tail_call_seq1/TestAmbiguousTailCallSeq1.py
lldb-api :: functionalities/tail_call_frames/ambiguous_tail_call_seq2/TestAmbiguousTailCallSeq2.py
lldb-api :: functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
lldb-api :: functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
lldb-api :: functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
lldb-api :: functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
lldb-api :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
lldb-api :: functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
lldb-api :: functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
lldb-api :: functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py

Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65410

show more ...

As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there.

This change doesn't include any change to move from selection dag to fast isel
and that will come with ot

As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there.

This change doesn't include any change to move from selection dag to fast isel
and that will come with other numbers that should help inform that decision.
There also haven't been any real debuggability studies with this pipeline yet,
this is just the initial start done so that people could see it and we could start
tweaking after.

Test updates: Outside of the newpm tests most of the updates are coming from either
optimization passes not run anymore (and without a compelling argument at the moment)
that were largely used for canonicalization in clang.

Original post:

http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html

Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65410

show more ...