I committed two quick fixes for Linux builds, where that unit test failed unreliably. a2dbb195d8ae and 7026a0cacaa0. Please correct that if the "0x" prefix is mandatory. If 0x is mandatory, please don't rely on the '#' flag, as it only outputs 0x for non-zero values.

Revise the statement on !setdagname

My bad. Add the missing period.

Revise documentation

I don't see this issue from the main branch. In fact, https://reviews.llvm.org/D149016 solves the issue and should not be "fixed". Could you double-check whether the main branch could reproduce this issue?

Add a common helper for !getdagarg, !setdagarg, and !setdagname

Revise following reviewer's comments. Now, !setdagname also accepts name to lookup arguments

In D151842#4387522, @simon_tatham wrote:

I wonder if it might make sense to allow !setdagname to take a string name argument, like !setdagarg and !getdagarg do?

Obviously, it makes no sense for !getdagname, because if you're trying to find the name of the argument called "foo", you already know the answer is "foo" (unless there isn't one at all, I suppose). But I can imagine that you might want to rename the "foo" argument to "bar", without first having to find out where it is.

If you abstract out the "look up by index or name" functionality as I suggest, then this wouldn't even be difficult to implement – just add another call to the same function.

Revise the commit message, which has different markdown syntax from rst.

Revise the documentation

In D151842#4385757, @Paul-C-Anagnostopoulos wrote:

I don't understand the descriptions of these new operators. I don't think you mean that it replaces the argument value with the key.

As getdagargs and getdagnames could be implemented upon getdagarg and getdagname, this patch is redundant.

In D151457#4383385, @fpetrogalli wrote:

In D151457#4382119, @hliao wrote:

In D151457#4380793, @fpetrogalli wrote:

Hey @hliao - thank you for this patch. Apparently we had a similar idea D151702 :)

I just have a couple of comments.

Thanks!

Francesco

I proposed another change introducing !getdagarg and !getdagname to access individual arguments instead of a list of them. Personally, I thought that should be more convenient.

Does it mean that you want to abandon this change?

Revise error message following reviewer's comment

In D151457#4380793, @fpetrogalli wrote:

Hey @hliao - thank you for this patch. Apparently we had a similar idea D151702 :)

I just have a couple of comments.

Thanks!

Francesco

Revise the out-of-range error message. Now, the range is from 0 to (numargs-1).

More tests

In D151602#4380256, @simon_tatham wrote:

It's not quite clear whether you mean this patch to be an alternative to D151457, or to go together with it. The two changes would clearly conflict, but one of your comments in the other change (https://reviews.llvm.org/D151457#4374848) made it sound as if you meant to do both?

If they're alternatives, then I prefer this one, because I love the extra feature of looking up a dag argument by its name instead of its index. I can see that being really useful.

Rebase and ping for review. The alternative approach is posted @ https://reviews.llvm.org/D151602

Rebase and ping for review

Fix clang-format issue

The alternative approach is uploaded @ https://reviews.llvm.org/D151602

Allow convertible types and update tests

Rebase

Now return ? if an argument has unmatching type. Tests are updated.

Rebase and kindly PING for review

Rebase and kindly PING for review

Revise following comments from reviewers

Rebase and kindly PING for review

Rebase and kindly PING review. Please let me know any pending issue to be addressed.

• Update TTI hook isValidAddrSpaceCast to be consistent with LLVM IR verifier
• Check the equal case in instcombine
• Add other valid cases in AMDGPU

Rebase and kindly PING for review

Rebase and kindling PING for review

Fix clang-format

Kindly PING for review

Add the target-specific usage

In D147025#4233724, @nikic wrote:

As far as I can tell, your motivating test cases do not require the TTI hook. They only need trivial address space casts (to the same address space).

Using TTI inside InstCombine is forbidden as a matter of policy. You would need to make an argument for why this exception should be allowed (it would probably go along the lines of "this should really be part of data layout"), so I would recommend to only handle this trivial case first and bypass the TTI issue.

Revise following reviewer's comment

Ping for review

Fix typos

a new keep test is added.

Add one more keep test

Rebase

Revise the formatting.

In D87858#3125630, @yaxunl wrote:

Hi Michael, would you like to continue working on this, or let someone from AMD to take over? Thanks.