[Local] Don't remove invoke of non-willreturn function

The code was only checking for memory side-effects, but not for
divergence side-effects. Replace this with a generic check.

[SimplifyCFG] Add test for invoke of nounwind non-willreturn function (NFC)

Test both the case with and without willreturn attribute.

Reland [SimplifyCFG] `markAliveBlocks()`: recognize that normal dest of `invoke`d `noreturn` function is `unreachable`

As per LangRef's definition of `noreturn` attribute:
```
noreturn
This functi

Reland [SimplifyCFG] `markAliveBlocks()`: recognize that normal dest of `invoke`d `noreturn` function is `unreachable`

As per LangRef's definition of `noreturn` attribute:
```
noreturn
This function attribute indicates that the function never returns
normally, hence through a return instruction.
This produces undefined behavior at runtime if the function
ever does dynamically return. nnotated functions may still
raise an exception, i.a., nounwind is not implied.
```

So if we `invoke` a `noreturn` function, and the normal destination
of an invoke is not an `unreachable`, point it at the new `unreachable`
block.

The change/fix from the original commit is that we now actually create
the new block, and don't just repurpose the original block,
because said normal destination block could have other users.

This reverts commit db1176ce66cf276b45ac3b90ea6b5ce62de56be7,
relanding commit 598833c987593ce192fa827f162cae8c867c9d43.

show more ...

[NFC][SimplifyCFG] Add test w/ shared normal dest of a `noreturn` `invoke`d function

Revert "[SimplifyCFG] `markAliveBlocks()`: recognize that normal dest of `invoke`d `noreturn` function is `unreachable`"

The normal destination may have other uses.

This reverts commit 598833c98759

Revert "[SimplifyCFG] `markAliveBlocks()`: recognize that normal dest of `invoke`d `noreturn` function is `unreachable`"

The normal destination may have other uses.

This reverts commit 598833c987593ce192fa827f162cae8c867c9d43.

show more ...

[SimplifyCFG] `markAliveBlocks()`: recognize that normal dest of `invoke`d `noreturn` function is `unreachable`

As per LangRef's definition of `noreturn` attribute:
```
noreturn
This function attr

[SimplifyCFG] `markAliveBlocks()`: recognize that normal dest of `invoke`d `noreturn` function is `unreachable`

As per LangRef's definition of `noreturn` attribute:
```
noreturn
This function attribute indicates that the function never returns
normally, hence through a return instruction.
This produces undefined behavior at runtime if the function
ever does dynamically return. nnotated functions may still
raise an exception, i.a., nounwind is not implied.
```

show more ...

[NFC][SimplifyCFG] Add test showing failure to drop normal dest of noreturn invoke

[Local] Do not introduce a new `llvm.trap` before `unreachable`

This is the second attempt to remove the `llvm.trap` insertion after
https://reviews.llvm.org/rGe14e7bc4b889dfaffb7180d176a03311df2d4a

[Local] Do not introduce a new `llvm.trap` before `unreachable`

This is the second attempt to remove the `llvm.trap` insertion after
https://reviews.llvm.org/rGe14e7bc4b889dfaffb7180d176a03311df2d4ae6
reverted the first one. It is not clear what the exact issue was back
then and it might already be gone by now, it has been >5 years after
all.

Replaces D106299.

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

show more ...

[SimplifyCFG] Tail-merging all blocks with `ret` terminator

Based ontop of D104598, which is a NFCI-ish refactoring.
Here, a restriction, that only empty blocks can be merged, is lifted.

Reviewed B

[SimplifyCFG] Tail-merging all blocks with `ret` terminator

Based ontop of D104598, which is a NFCI-ish refactoring.
Here, a restriction, that only empty blocks can be merged, is lifted.

Reviewed By: rnk

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

show more ...

[NFC][SimplifyCFG] Autogenerate check lines in many test files

These are potentially being affected by an upcoming patch.

[SimplifyCFG] MergeBlockIntoPredecessor() already knows how to preserve DomTree

... so just ensure that we pass DomTreeUpdater it into it.

Fixes DomTree preservation for a large number of tests,
al

[SimplifyCFG] MergeBlockIntoPredecessor() already knows how to preserve DomTree

... so just ensure that we pass DomTreeUpdater it into it.

Fixes DomTree preservation for a large number of tests,
all of which are marked as such so that they do not regress.

show more ...

[IR] Convert null-pointer-is-valid into an enum attribute

The "null-pointer-is-valid" attribute needs to be checked by many
pointer-related combines. To make the check more efficient, convert
it fro

[IR] Convert null-pointer-is-valid into an enum attribute

The "null-pointer-is-valid" attribute needs to be checked by many
pointer-related combines. To make the check more efficient, convert
it from a string into an enum attribute.

In the future, this attribute may be replaced with data layout
properties.

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

show more ...

Revert "Temporarily Revert "Add basic loop fusion pass.""

The reversion apparently deleted the test/Transforms directory.

Will be re-reverting again.

llvm-svn: 358552

llvm: Add support for "-fno-delete-null-pointer-checks"

Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.

More

llvm: Add support for "-fno-delete-null-pointer-checks"

Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.

More details : https://lkml.org/lkml/2018/4/4/601

GCC option description for -fdelete-null-pointer-checks:
This Assume that programs cannot safely dereference null pointers,
and that no code or data element resides at address zero.

-fno-delete-null-pointer-checks is the inverse of this implying that
null pointer dereferencing is not undefined.

This feature is implemented in LLVM IR in this CL as the function attribute
"null-pointer-is-valid"="true" in IR (Under review at D47894).
The CL updates several passes that assumed null pointer dereferencing is
undefined to not optimize when the "null-pointer-is-valid"="true"
attribute is present.

Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv

Reviewed By: efriedma, george.burgess.iv

Subscribers: eraman, haicheng, george.burgess.iv, drinkcat, theraven, reames, sanjoy, xbolva00, llvm-commits

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

llvm-svn: 336613

show more ...

Revert "[SimplifyCFG] Stop inserting calls to llvm.trap for UB"

This reverts commit r273778, it seems to break UBSan :/

llvm-svn: 273779

[SimplifyCFG] Stop inserting calls to llvm.trap for UB

SimplifyCFG had logic to insert calls to llvm.trap for two very
particular IR patterns: stores and invokes of undef/null.

While InstCombine ca

[SimplifyCFG] Stop inserting calls to llvm.trap for UB

SimplifyCFG had logic to insert calls to llvm.trap for two very
particular IR patterns: stores and invokes of undef/null.

While InstCombine canonicalizes certain undefined behavior IR patterns
to stores of undef, phase ordering means that this cannot be relied upon
in general.

There are much better tools than llvm.trap: UBSan and ASan.

N.B. I could be argued into reverting this change if a clear argument as
to why it is important that we synthesize llvm.trap for stores, I'd be
hard pressed to see why it'd be useful for invokes...

llvm-svn: 273778

show more ...

Move the personality function from LandingPadInst to Function

The personality routine currently lives in the LandingPadInst.

This isn't desirable because:
- All LandingPadInsts in the same function

Move the personality function from LandingPadInst to Function

The personality routine currently lives in the LandingPadInst.

This isn't desirable because:
- All LandingPadInsts in the same function must have the same
personality routine. This means that each LandingPadInst beyond the
first has an operand which produces no additional information.

- There is ongoing work to introduce EH IR constructs other than
LandingPadInst. Moving the personality routine off of any one
particular Instruction and onto the parent function seems a lot better
than have N different places a personality function can sneak onto an
exceptional function.

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

llvm-svn: 239940

show more ...

Update Transforms tests to use CHECK-LABEL for easier debugging. No functionality change.

This update was done with the following bash script:

find test/Transforms -name "*.ll" | \
while read N

Update Transforms tests to use CHECK-LABEL for easier debugging. No functionality change.

This update was done with the following bash script:

find test/Transforms -name "*.ll" | \
while read NAME; do
echo "$NAME"
if ! grep -q "^; *RUN: *llc" $NAME; then
TEMP=`mktemp -t temp`
cp $NAME $TEMP
sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \
while read FUNC; do
sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP
done
mv $TEMP $NAME
fi
done

llvm-svn: 186268

show more ...

fix PR13339 (remove the predecessor from the unwind BB when removing an invoke)

llvm-svn: 160325

fix the regression I introduced in r159385 (it's necessary to update PHI nodes in unwind BB

llvm-svn: 159534

make simplifyCFG erase invokes to readonly/readnone functions

llvm-svn: 159385

improve optimization of invoke instructions:
- simplifycfg: invoke undef/null -> unreachable
- instcombine: invoke new -> invoke expect(0, 0) (an arbitrary NOOP intrinsic; only done if the all

improve optimization of invoke instructions:
- simplifycfg: invoke undef/null -> unreachable
- instcombine: invoke new -> invoke expect(0, 0) (an arbitrary NOOP intrinsic; only done if the allocated memory is unused, of course)
- verifier: allow invoke of intrinsics (to make the previous step work)

llvm-svn: 159146

show more ...