Rebase

Rebase

Rebase

Keep alphabetical ordering in CMakeLists.txt

In D125207#3505163, @yonghong-song wrote:

@Jim Thanks for the updated commit message. Please go ahead to merge to llvm-project main branch if you have write permission. Otherwise, please provide me with peoper git author signature "<name> <email address>" and I can help push the patch for you.

This patch only add missing case in getMemConstraintName.
Could someone help to take a review. Thanks.

It not just happen in RISCVPassConfig. If we inherit other class such as RISCVISelDAGToDAG.h and RISCVISelLowering.h, it still need to deal with the newly added override function issue.

In D120695#3353293, @craig.topper wrote:

Creating a new class seems fragile. Does your class call the RISCVPassConfig version of the methods you override? What if your class overrides a method that RISCVPassConfig doesn't override today, but does in the future. Will your class call the newly added override when its done with your override?

In D120695#3351520, @jrtc27 wrote:

Note that git grep ' : public TargetPassConfig' llvm/lib/Target turns up 21 results, exactly one for each backend, and every single one lives in the backend's TargetMachine.cpp. So moving it to a header, or adding a second one, would go against the convention of every single backend in tree.

In D120695#3351508, @jrtc27 wrote:

Inheriting from the pass doesn't make sense, just change the implementations. The TargetPassConfig has access to the TM for a reason. As someone with significant downstream changes I am sympathetic to changing upstream code to be more accommodating, but this change just seems motivated by an arbitrary downstream decision that goes against the intent of LLVM's structure just to avoid the occasional merge conflict (RISCVPassConfig hardly changes much).

In D120695#3350392, @craig.topper wrote:

Isn’t the function that returns the class in this cpp file? Why are you able to change that function in your downstream but can’t add your new class to the cpp in your downstream?

In D120695#3350370, @craig.topper wrote:

Can you clarify what *why* this helps downstream?

Add commit log

clang-format

Remove inst alias smbb32 (alias to mulsr64) and kmar64 (alias to kmar64).
Having the same instruction in two different extensions under two different name is gone.

In D119529#3313680, @sdesmalen wrote:

Can you add a test for this change?

Rebase

Rebase

Rebase

Kindly ping.

In D108189#3188343, @zixuan-wu wrote:

Hi, @Jim.
What time is P extension going to upstream to community since it's been no update for some months?

Hi @zixuan-wu,

In D116580#3247458, @myhsu wrote:

This revision seems to be in conflict with D116993 . How are you going to resolve it? (e.g. rebasing this one on top of D116993 and setup a dependency)

Add missing unrenamed

Formatting

In D117196#3240173, @luismarques wrote:

Please see D92464 for a discussion about the issues with this.

Fix tests

Rebase

Rebase