[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.

show more ...

[Analysis] Use *{Set,Map}::contains (NFC)

[NFC] Use single quotes for single char output during `printPipline`

Reviewed By: arsenm

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

[StackLifetime] Fix sign compare warning (NFC)

[IR] Add AllocaInst::getAllocationSize() (NFC)

When fetching allocation sizes, we almost always want to have the
size in bytes, but we were only providing an InBits API. Also add
the corresponding b

[IR] Add AllocaInst::getAllocationSize() (NFC)

When fetching allocation sizes, we almost always want to have the
size in bytes, but we were only providing an InBits API. Also add
the corresponding byte-based conjugate to save some *8 and /8
juggling everywhere.

show more ...

[StackLifetime] More efficient loop for LivenessType::Must

CFG with cycles may requires additional passes of "while (Changed)"
iteration if to propagate data back from latter blocks to earlier block

[StackLifetime] More efficient loop for LivenessType::Must

CFG with cycles may requires additional passes of "while (Changed)"
iteration if to propagate data back from latter blocks to earlier blocks,
ordered according to depth_fist.

OR logic, used for ::May, converge to stable state faster then AND logic
use for ::Must.

Though the better solution is to switch to some some form of queue, but
having that this one is good enough, I will consider to do that later.

We can switch ::Must to OR logic if we calculate "may be dead" instead
of direct "must be alive" and then convert values to match existing
interface.

Additionally it fixes correctness in "@cycle" test.

Reviewed By: kstoimenov, fmayer

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

show more ...

[NFC][StackLifetime] Rename local variable

The next patch will require more generic name.

[NFC][StackLifetime] Remove local variable

[Analysis] Qualify auto variables in for loops (NFC)

[llvm] Don't use Optional::getValue (NFC)

Cleanup includes: LLVMAnalysis

Number of lines output by preprocessor:
before: 1065940348
after: 1065307662

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Diff

Cleanup includes: LLVMAnalysis

Number of lines output by preprocessor:
before: 1065940348
after: 1065307662

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120659

show more ...

[NPM] Added -print-pipeline-passes print params for a few passes.

Added '-print-pipeline-passes' printing of parameters for those passes
declared with *_WITH_PARAMS macro in PassRegistry.def.

Note

[NPM] Added -print-pipeline-passes print params for a few passes.

Added '-print-pipeline-passes' printing of parameters for those passes
declared with *_WITH_PARAMS macro in PassRegistry.def.

Note that it only prints the parameters declared inside *_WITH_PARAMS as
in a few cases there appear to be additional parameters not parsable.

The following passes are now covered (i.e. all of those with *_WITH_PARAMS in
PassRegistry.def).

LoopExtractorPass - loop-extract
HWAddressSanitizerPass - hwsan
EarlyCSEPass - early-cse
EntryExitInstrumenterPass - ee-instrument
LowerMatrixIntrinsicsPass - lower-matrix-intrinsics
LoopUnrollPass - loop-unroll
AddressSanitizerPass - asan
MemorySanitizerPass - msan
SimplifyCFGPass - simplifycfg
LoopVectorizePass - loop-vectorize
MergedLoadStoreMotionPass - mldst-motion
GVN - gvn
StackLifetimePrinterPass - print<stack-lifetime>
SimpleLoopUnswitchPass - simple-loop-unswitch

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

show more ...

StackLifetime: Remove asserts for multiple lifetime intrinsics.

According to the langref, it is valid to have multiple consecutive
lifetime start or end intrinsics on the same object.

For llvm.life

StackLifetime: Remove asserts for multiple lifetime intrinsics.

According to the langref, it is valid to have multiple consecutive
lifetime start or end intrinsics on the same object.

For llvm.lifetime.start:
"If ptr [...] is a stack object that is already alive, it simply
fills all bytes of the object with poison."

For llvm.lifetime.end:
"Calling llvm.lifetime.end on an already dead alloca is no-op."

However, we currently fail an assertion in such cases. I've observed
the assertion failure when the loop vectorization pass duplicates
the intrinsic.

We can conservatively handle these intrinsics by ignoring all but
the first one, which can be implemented by removing the assertions.

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

show more ...

When dumping results of StackLifetime, it will print the following
log:

BB [7, 8): begin {}, end {}, livein {}, liveout {}
BB [1, 2): begin {}, end {}, livein {}, liveout {}
...

But it is not con

When dumping results of StackLifetime, it will print the following
log:

BB [7, 8): begin {}, end {}, livein {}, liveout {}
BB [1, 2): begin {}, end {}, livein {}, liveout {}
...

But it is not convenient to know what the basic block is.
So I add the basic block name to it.

Reviewed By: vitalybuka
TestPlan: check-llvm
Differential Revision: https://reviews.llvm.org/D87152

show more ...

[StackSafety] Ignore allocas with partial lifetime markers

Reviewed By: eugenis

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

[StackSafety] Skip ambiguous lifetime analysis

If we can't identify alloca used in lifetime marker we
need to assume to worst case scenario.

Reviewed By: eugenis

Differential Revision: https://rev

[StackSafety] Skip ambiguous lifetime analysis

If we can't identify alloca used in lifetime marker we
need to assume to worst case scenario.

Reviewed By: eugenis

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

show more ...

Revert "[StackSafety] Skip ambiguous lifetime analysis"

This reverts commit 0b2616a8045cb776ea1514c3401d0a8577de1060.

Crashes with safe-stack.

[StackSafety] Skip ambiguous lifetime analysis

If we can't identify alloca used in lifetime marker we
need to assume to worst case scenario.

Reviewed By: eugenis

Differential Revision: https://rev

[StackSafety] Skip ambiguous lifetime analysis

If we can't identify alloca used in lifetime marker we
need to assume to worst case scenario.

Reviewed By: eugenis

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

show more ...

[StackSafety,NFC] Don't rerun on LiveIn change

[StackSafety,NFC] Fix comment

[StackSafety] Add StackLifetime::isAliveAfter

This function is going to be added into StackSafety checks.
This patch uses function in ::print implementation to make sure
that it works as expected.

[SafeStack,NFC] Print liveness for all instrunctions

[StackSafety,NFC] Replace map with vector

We don't need to lookup InstructionNumbering by number, so
we can use vector with index as assigned number.

[StackSafety,NFC] Don't test terminators

Code does not track terminators and do not expose them through interface.
State there is just a state of the last instruction or entry.
So this information i

[StackSafety,NFC] Don't test terminators

Code does not track terminators and do not expose them through interface.
State there is just a state of the last instruction or entry.
So this information is just redundant and doesn't need to be tested.

show more ...

[StackSafety] Add "Must Live" logic

Summary:
Extend StackLifetime with option to calculate liveliness
where alloca is only considered alive on basic block entry
if all non-dead predecessors had it a

[StackSafety] Add "Must Live" logic

Summary:
Extend StackLifetime with option to calculate liveliness
where alloca is only considered alive on basic block entry
if all non-dead predecessors had it alive at terminators.

Depends on D82043.

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

show more ...