[GlobalOpt] Don't remove inalloca from varargs functions

Varargs and inalloca have a weird interaction where varargs are actually
passed via the inalloca alloca. Removing inalloca breaks the varargs

[GlobalOpt] Don't remove inalloca from varargs functions

Varargs and inalloca have a weird interaction where varargs are actually
passed via the inalloca alloca. Removing inalloca breaks the varargs
because they're still not passed as separate arguments.

Fixes #58718

Reviewed By: rnk

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

(cherry picked from commit 8c49b01a1ee051ab2c09be4cffc83656ccc0fbe6)

show more ...

Use llvm::less_first and llvm::less_second (NFC)

[MemoryBuiltins] Avoid isAllocationFn() call before checking removable alloc

Alloc directly checking whether a given call is a removable
allocation, instead of first checking whether it is an alloca

[MemoryBuiltins] Avoid isAllocationFn() call before checking removable alloc

Alloc directly checking whether a given call is a removable
allocation, instead of first checking whether it is an allocation
first.

show more ...

[IR] Remove Constant::canTrap() (NFC)

As integer div/rem constant expressions are no longer supported,
constants can no longer trap and are always safe to speculate.
Remove the Constant::canTrap() m

[IR] Remove Constant::canTrap() (NFC)

As integer div/rem constant expressions are no longer supported,
constants can no longer trap and are always safe to speculate.
Remove the Constant::canTrap() method and its usages.

show more ...

[GlobalOpt] Perform store->dominated load forwarding for stored once globals

The initial land incorrectly optimized forwarding non-Constants in non-nosync/norecurse functions. Bail on non-Constants

[GlobalOpt] Perform store->dominated load forwarding for stored once globals

The initial land incorrectly optimized forwarding non-Constants in non-nosync/norecurse functions. Bail on non-Constants since norecurse should cause global -> alloca promotion anyway.

The initial land also incorrectly assumed that StoredOnceStore was the only store to the global, but it actually means that only one value other than the global initializer is stored. Add a check that there's only one store.

Compile time tracker:
https://llvm-compile-time-tracker.com/compare.php?from=c80b88ee29f34078d2149de94e27600093e6c7c0&to=ef2c2b7772424b6861a75e794f3c31b45167304a&stat=instructions

Reviewed By: nikic, asbirlea, jdoerfert

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

show more ...

Reland [GlobalOpt] Preserve CFG analyses

The only place we modify the CFG is when calling
removeUnreachableBlocks(), so insert a callback there which invalidates
analyses for that function (or recom

Reland [GlobalOpt] Preserve CFG analyses

The only place we modify the CFG is when calling
removeUnreachableBlocks(), so insert a callback there which invalidates
analyses for that function (or recomputes DT in the legacy PM).

We may delete functions, make sure to clear analyses for those
functions. (this was missed in the original revision)

Small compile time wins across the board:
https://llvm-compile-time-tracker.com/compare.php?from=f444ea8ce0aaaa5ec1a4129809389da15cc41396&to=698f41f4fc26cbf1006ed5d88e9d658edfc5b749&stat=instructions

Reviewed By: nikic

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

show more ...

Revert "[GlobalOpt] Perform store->dominated load forwarding for stored once globals"

This reverts commit 6f348b146b69a50d5fb1b9fbfd14bc1d204e45c4.

Am seeing internal test failures plus a linux ker

Revert "[GlobalOpt] Perform store->dominated load forwarding for stored once globals"

This reverts commit 6f348b146b69a50d5fb1b9fbfd14bc1d204e45c4.

Am seeing internal test failures plus a linux kernel breakage reported due to this.

show more ...

Revert "[GlobalOpt] Preserve CFG analyses"

This reverts commit cc65f3e167144c39ef9ca3a69c3148b71dcab496.

Causes crashes: https://github.com/llvm/llvm-project/issues/56131

[GlobalOpt] Preserve CFG analyses

The only place we modify the CFG is when calling
removeUnreachableBlocks(), so insert a callback there which invalidates
analyses for that function (or recomputes D

[GlobalOpt] Preserve CFG analyses

The only place we modify the CFG is when calling
removeUnreachableBlocks(), so insert a callback there which invalidates
analyses for that function (or recomputes DT in the legacy PM).

Small compile time wins across the board:
https://llvm-compile-time-tracker.com/compare.php?from=f444ea8ce0aaaa5ec1a4129809389da15cc41396&to=698f41f4fc26cbf1006ed5d88e9d658edfc5b749&stat=instructions

Reviewed By: nikic

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

show more ...

[GlobalOpt] Perform store->dominated load forwarding for stored once globals

Compile time tracker:
https://llvm-compile-time-tracker.com/compare.php?from=1e556f459b44dd0ca4073e932f66ecb6f40fe31a&to=

[GlobalOpt] Perform store->dominated load forwarding for stored once globals

Compile time tracker:
https://llvm-compile-time-tracker.com/compare.php?from=1e556f459b44dd0ca4073e932f66ecb6f40fe31a&to=6d7bed4e1e72c6a8592748626091274209740a40&stat=instructions

Reviewed By: nikic

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

show more ...

[NFC][GlobalOpt] Remove unused parameters

[NFC] Remove commented cerr debugging loggings

There are some unused cerr debugging loggings in the codes. It is weird
to remain such commented debug helpers in the product.

[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFC

Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the err

[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFC

Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the error has been removed,
cl::ZeroOrMore is unneeded.

Also remove cl::init(false) while touching the lines.

show more ...

[GlobalOpt] Enable optimization of constructors with different priorities

Adjust `optimizeGlobalCtorsList` to handle the case of different priorities.
This addresses the issue https://github.com/llv

[GlobalOpt] Enable optimization of constructors with different priorities

Adjust `optimizeGlobalCtorsList` to handle the case of different priorities.
This addresses the issue https://github.com/llvm/llvm-project/issues/55083.

Test plan: ninja check-all

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

show more ...

[GlobalOpt] Iterate over replaced values deterministically to constprop

If there are pre-existing dead instructions, the order we visit replaced
values can cause us sometimes to not delete dead inst

[GlobalOpt] Iterate over replaced values deterministically to constprop

If there are pre-existing dead instructions, the order we visit replaced
values can cause us sometimes to not delete dead instructions.

The added test non-deterministically failed without the change.

show more ...

[NFC] Rename Instrinsic to Intrinsic

[GlobalOpt] Handle non-instruction MTI source (PR54572)

This was reusing a cast to GlobalVariable to check for an
Instruction, which means we'll try to dereference a null pointer
if it's not actuall

[GlobalOpt] Handle non-instruction MTI source (PR54572)

This was reusing a cast to GlobalVariable to check for an
Instruction, which means we'll try to dereference a null pointer
if it's not actually a GlobalVariable. We should be casting
MTI->getSource() instead.

I don't think this problem is really specific to opaque pointers,
but it certainly makes it a lot easier to reproduce.

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

show more ...

Cleanup includes: Transforms/IPO

Preprocessor output diff: -238205 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.ll

Cleanup includes: Transforms/IPO

Preprocessor output diff: -238205 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D122183

show more ...

[GlobalOpt] Don't replace alias with aliasee if either alias/aliasee may be preemptible

Generalize D99629 for ELF. A default visibility non-local symbol is preemptible
in a -shared link. `isInterpos

[GlobalOpt] Don't replace alias with aliasee if either alias/aliasee may be preemptible

Generalize D99629 for ELF. A default visibility non-local symbol is preemptible
in a -shared link. `isInterposable` is an insufficient condition.

Moreover, a non-preemptible alias may be referenced in a sub constant expression
which intends to lower to a PC-relative relocation. Replacing the alias with a
preemptible aliasee may introduce a linker error.

Respect dso_preemptable and suppress optimization to fix the abose issues. With
the change, `alias = 345` will not be rewritten to use aliasee in a `-fpic`
compile.
```
int aliasee;
extern int alias __attribute__((alias("aliasee"), visibility("hidden")));
void foo() { alias = 345; } // intended to access the local copy
```

While here, refine the condition for the alias as well.

For some binary formats like COFF, `isInterposable` is a sufficient condition.
But I think canonicalization for the changed case has little advantage, so I
don't bother to add the `Triple(M.getTargetTriple()).isOSBinFormatELF()` or
`getPICLevel/getPIELevel` complexity.

For instrumentations, it's recommended not to create aliases that refer to
globals that have a weak linkage or is preemptible. However, the following is
supported and the IR needs to handle such cases.
```
int aliasee __attribute__((weak));
extern int alias __attribute__((alias("aliasee")));
```

There are other places where GlobalAlias isInterposable usage may need to be
fixed.

Reviewed By: rnk

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

show more ...

[DebugInfo][SROA] Correct debug info for global variables in case of SROA

The existing handling produced crash for test case (attached with patch).
Now the function transferSRADebugInfo is modified

[DebugInfo][SROA] Correct debug info for global variables in case of SROA

The existing handling produced crash for test case (attached with patch).
Now the function transferSRADebugInfo is modified to
- Ignore the current variable if it starts after the current Fragment.
- Ignore the current variable if it ends before the current Fragment.
- Generate (!DIExpression()) if current variable completely fits the
current Fragment.
- Otherwise (as earlier), generate the DW_OP_LLVM_fragment in IR if current
Fragment partially defines current variable.

Reviewed By: aprantl

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

show more ...

Revert "[GlobalOpt] Don't replace alias with aliasee if either alias/aliasee may be preemptible"

This reverts commit 30e8f83c84c5a302a559722fc0d2973dc3f425ee.

Causes huge compile time regressions o

Revert "[GlobalOpt] Don't replace alias with aliasee if either alias/aliasee may be preemptible"

This reverts commit 30e8f83c84c5a302a559722fc0d2973dc3f425ee.

Causes huge compile time regressions on certain large files. Will followup offline with author.

show more ...

[GlobalOpt] Don't replace alias with aliasee if either alias/aliasee may be preemptible

Generalize D99629 for ELF. A default visibility non-local symbol is preemptible
in a -shared link. `isInterpos

[GlobalOpt] Don't replace alias with aliasee if either alias/aliasee may be preemptible

Generalize D99629 for ELF. A default visibility non-local symbol is preemptible
in a -shared link. `isInterposable` is an insufficient condition.

Moreover, a non-preemptible alias may be referenced in a sub constant expression
which intends to lower to a PC-relative relocation. Replacing the alias with a
preemptible aliasee may introduce a linker error.

Respect dso_preemptable and suppress optimization to fix the abose issues. With
the change, `alias = 345` will not be rewritten to use aliasee in a `-fpic`
compile.
```
int aliasee;
extern int alias __attribute__((alias("aliasee"), visibility("hidden")));
void foo() { alias = 345; } // intended to access the local copy
```

While here, refine the condition for the alias as well.

For some binary formats like COFF, `isInterposable` is a sufficient condition.
But I think canonicalization for the changed case has little advantage, so I
don't bother to add the `Triple(M.getTargetTriple()).isOSBinFormatELF()` or
`getPICLevel/getPIELevel` complexity.

For instrumentations, it's recommended not to create aliases that refer to
globals that have a weak linkage or is preemptible. However, the following is
supported and the IR needs to handle such cases.
```
int aliasee __attribute__((weak));
extern int alias __attribute__((alias("aliasee")));
```

There are other places where GlobalAlias isInterposable usage may need to be
fixed.

Reviewed By: rnk

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

show more ...

[GlobalOpt] Avoid early exit before dead constant check

In a similar vein to 236fbf571dc6cebcb81ac5187a170c8de6d5bc0e,
make sure we don't early-exit before the dead constant check.

[GlobalOpt] Generalize malloc-to-global for any allocation function

We can generalize the malloc-to-global transform for other allocation functions which are both a) removable, and b) have a known i

[GlobalOpt] Generalize malloc-to-global for any allocation function

We can generalize the malloc-to-global transform for other allocation functions which are both a) removable, and b) have a known initialization value.

One subtlety that I want to point out - mostly because I hadn't realized it was true until I took a closer look - is that the existing code doesn't prove that initialization/malloc happens only once. The initialization function can be called multiple times. This is correct without special handling for malloc as undef can map to any value previously written, but a non-undef initializing allocation it means we may end up memseting the new global repeatedly. In particular, this means it's not legal to fold the memset into the initializer of the global.

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

show more ...

[GlobalOpt] Drop an incorrect check

This was a last-minute addition to D117249, and of course I ended
up inverting the condition in a way that caused an uninitialized
memory read.

I've dropped it e

[GlobalOpt] Drop an incorrect check

This was a last-minute addition to D117249, and of course I ended
up inverting the condition in a way that caused an uninitialized
memory read.

I've dropped it entirely, as I don't think we actually care whether
the size is zero or not here. The previous code wasn't checking
this either.

show more ...