Use llvm::less_first (NFC)

Revert "[llvm][clang][bolt][NFC] Use llvm::less_first() when applicable"

This reverts commit 3988bd13988aad72ec979beb2361e8738584926b.

Did not build on this bot:
https://lab.llvm.org/buildbot#build

Revert "[llvm][clang][bolt][NFC] Use llvm::less_first() when applicable"

This reverts commit 3988bd13988aad72ec979beb2361e8738584926b.

Did not build on this bot:
https://lab.llvm.org/buildbot#builders/215/builds/6372

/usr/include/c++/9/bits/predefined_ops.h:177:11: error: no match for call to
‘(llvm::less_first) (std::pair<long unsigned int, llvm::bolt::BinaryBasicBlock*>&, const std::pair<long unsigned int, std::nullptr_t>&)’
177 | { return bool(_M_comp(*__it, __val)); }

show more ...

[llvm][clang][bolt][NFC] Use llvm::less_first() when applicable

One could reuse this functor instead of rolling out your own version.
There were a couple other cases where the code was similar, but

[llvm][clang][bolt][NFC] Use llvm::less_first() when applicable

One could reuse this functor instead of rolling out your own version.
There were a couple other cases where the code was similar, but not
quite the same, such as it might have an assertion in the lambda or other
constructs. Thus, I've not touched any of those, as it might change the
behavior in some way.

As per https://discourse.llvm.org/t/submitting-simple-nfc-patches/62640/3?u=steakhal
Chris Lattner
> LLVM intentionally has a “yes, you can apply common sense judgement to
> things” policy when it comes to code review. If you are doing mechanical
> patches (e.g. adopting less_first) that apply to the entire monorepo,
> then you don’t need everyone in the monorepo to sign off on it. Having
> some +1 validation from someone is useful, but you don’t need everyone
> whose code you touch to weigh in.

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

show more ...

Use a sorted array instead of a map to store AttrBuilder string attributes

Using and std::map<SmallString, SmallString> for target dependent attributes is
inefficient: it makes its constructor sligh

Use a sorted array instead of a map to store AttrBuilder string attributes

Using and std::map<SmallString, SmallString> for target dependent attributes is
inefficient: it makes its constructor slightly heavier, and involves extra
allocation for each new string attribute. Storing the attribute key/value as
strings implies extra allocation/copy step.

Use a sorted vector instead. Given the low number of attributes generally
involved, this is cheaper, as showcased by

https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions

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

show more ...

[llvm-reduce] Count chunks by running a preliminary reduction

Having a separate counting method runs the risk of a mismatch between
the actual reduction method and the counting method.

Instead, cre

[llvm-reduce] Count chunks by running a preliminary reduction

Having a separate counting method runs the risk of a mismatch between
the actual reduction method and the counting method.

Instead, create an Oracle that always returns true for shouldKeep(), run
the reduction, and count how many times shouldKeep() was called. The
module should not be modified if shouldKeep() always returns true.

Reviewed By: Meinersbur

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

show more ...

[NFC][llvm-reduce] Cleanup types

Use Module& wherever possible.
Since every reduction immediately turns Chunks into an Oracle, directly pass Oracle instead.

Reviewed By: hans

Differential Revision

[NFC][llvm-reduce] Cleanup types

Use Module& wherever possible.
Since every reduction immediately turns Chunks into an Oracle, directly pass Oracle instead.

Reviewed By: hans

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

show more ...

[NFC][AttributeList] Replace index_begin/end with an iterator

We expose the fact that we rely on unsigned wrapping to iterate through
all indexes. This can be confusing. Rather, keeping it as an
imp

[NFC][AttributeList] Replace index_begin/end with an iterator

We expose the fact that we rely on unsigned wrapping to iterate through
all indexes. This can be confusing. Rather, keeping it as an
implementation detail through an iterator is less confusing and is less
code.

Reviewed By: rnk

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

show more ...

[llvm] Add enum iteration to Sequence

This patch allows iterating typed enum via the ADT/Sequence utility.

It also changes the original design to better separate concerns:
- `StrongInt` only deals

[llvm] Add enum iteration to Sequence

This patch allows iterating typed enum via the ADT/Sequence utility.

It also changes the original design to better separate concerns:
- `StrongInt` only deals with safe `intmax_t` operations,
- `SafeIntIterator` presents the iterator and reverse iterator
interface but only deals with safe `StrongInt` internally.
- `iota_range` only deals with `SafeIntIterator` internally.

This design ensures that operations are always valid. In particular,
"Out of bounds" assertions fire when:
- the `value_type` is not representable as an `intmax_t`
- iterator operations make internal computation underflow/overflow
- the internal representation cannot be converted back to `value_type`

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

show more ...

Revert "[llvm] Add enum iteration to Sequence"

This reverts commit a006af5d6ec6280034ae4249f6d2266d726ccef4.

[llvm] Add enum iteration to Sequence

This patch allows iterating typed enum via the ADT/Sequence utility.

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

[llvm-reduce] Add header guards and fix clang-tidy warnings

Add header guards and fix other clang-tidy warnings in .h files.
Also align misaligned header docs

Reviewed By: aeubanks

Differential Re

[llvm-reduce] Add header guards and fix clang-tidy warnings

Add header guards and fix other clang-tidy warnings in .h files.
Also align misaligned header docs

Reviewed By: aeubanks

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

show more ...

[llvm-reduce] Reducing attributes

Summary:
This handles all three places where attributes could currently be - `GlobalVariable`, `Function` and `CallBase`.
For last two, it correctly handles all thr

[llvm-reduce] Reducing attributes

Summary:
This handles all three places where attributes could currently be - `GlobalVariable`, `Function` and `CallBase`.
For last two, it correctly handles all three possible attribute locations (return value, arguments and function itself)

There was a previous attempt at it D73853,
which was committed in rGfc62b36a000681c01e993242b583c5ec4ab48a3c,
but then reverted all the way back in rGb12176d2aafa0ccb2585aa218fc3b454ba84f2a9
due to some (osx?) test failures.

Reviewers: nickdesaulniers, dblaikie, diegotf, george.burgess.iv, jdoerfert, Tyker, arsenm

Reviewed By: nickdesaulniers

Subscribers: wdng, MaskRay, arsenm, llvm-commits, mgorny

Tags: #llvm

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

show more ...

[llvm-reduce] add ReduceAttribute delta pass

Summary:
The output from llvm-reduce still has significantly more attributes than
bugpoint does. Teach llvm-reduce to remove attributes.

Reviewers: die

[llvm-reduce] add ReduceAttribute delta pass

Summary:
The output from llvm-reduce still has significantly more attributes than
bugpoint does. Teach llvm-reduce to remove attributes.

Reviewers: diegotf, dblaikie, george.burgess.iv

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

show more ...